Authentication in Microsoft 365

Hello, my fellow technological knowledge seekers – This is my first blog on Skylines, so I hope you guys enjoy it! 

As you develop a plan of attack to study and pass your MS-100: Microsoft 365 Identity and Services examination, you have likely encountered through the Skills Measurement Guide that a large chunk of the exam (about 40% of it) is around the design, implementation, and management of an identity strategy. This includes which methods of authentication your organization wishes to support. 

This blog is going to give you a small preview sampling of the different authentication options offered up in M365.  

The best place to start is probably the beginning and that’s with the detail around the supported methods of authentication into Azure AD. Remember this. While we’re talking about identity sync to access and utilize M365 services the “real” work is being done in Azure AD in conjunction with your on-prem identity solution.  

This is why your authentication method is so important. It sets the framework regarding how your users are going to authentication into the environment. Now before you make such an important decision it’s important to also factor in your company’s policies and security requirements as this can affect that decision heavily. Additionally, the same can be said about the current identity solution you’re synchronizing against. For the purpose of the exam, you are unlikely to encounter any questions about cloud-only identity (which means you don’t have an on-prem identity solution to synchronize with. This is due to the fact that this setup is the easiest to deploy and when you develop exam questions the options for a solution are pretty straight forward…  

 
themoreyouknow.png
 

Anyway, I digress…

So, let’s talk about the authentication options – There’s two main options: Cloud Authentication and Federated Authentication.

  • Cloud Authentication - When you choose this authentication method Azure AD handles the authentication process for user's sign-in. With cloud authentication you can choose from two options

    • Password hash synchronization (PHS) - Password Hash Sync enables users to use the same username and password that they use on-premises without having to deploy any additional infrastructure besides Azure AD Connect.

    • Pass-through authentication (PTA) - This option is similar to password hash sync but provides a simple password validation using on-premises software agents for organizations with strong security and compliance policies.

  • Federated authentication - When you choose this authentication method Azure AD will hand off the authentication process to a separate trusted authentication system, such as AD FS or a third-party federation system, to validate the user's sign-in.

Within the cloud authentication models we have two methods (Password Hash Sync and Pass-through authentication).

The way PHS works is that the hash of a user password is synchronized between your on-prem AD Domain Services and Azure AD. If a user changes or resets the password on-prem, the hash is synchronized with Azure AD immediately. This allows your users to use the same password for both cloud resources and on-prem resources. The passwords themselves are NOT sent or stored in Azure AD in clear text (just the hash) – Now you can enable password write-back to enable a self-service password reset in Azure AD but that option is not enabled by default and there are some licensing stipulations with PW write-back functionality.

A more thorough technical description of PHS can be found here

 
Figure 1 – Password Hash Synchronization Authentication Source: Azure AD Connect user sign-in options

Figure 1 – Password Hash Synchronization Authentication
Source:
Azure AD Connect user sign-in options

 

PTA works a little differently. Similar to PHS the password doesn’t need to be in Azure AD. The password is validated against the on-prem identity in Active Directory. This allows the utilization of policies and GPOs to be used or evaluated during authentication. PTA is different in the sense that it leverages and agent-based connector software that runs on a Windows Server domain member that runs on-prem. This agent is responsible for listening for password requests. Now you may be wondering, that doesn’t sound secure… Don’t worry my friend – This agent doesn’t require any inbound ports to be open to the Internet.  

A more thorough technical description of PTA can be found here

 
Figure 2: Pass Through Authentication Source: Azure AD Connect user sign-in options

Figure 2: Pass Through Authentication
Source:
Azure AD Connect user sign-in options

 

You can also leverage Azure AD Seamless Single Sign-On in as well. Now Seamless SSO isn’t specific to PHS or PTA but one thing is certain about it, you CANNOT use it with ADFS. The one important requirement regarding Seamless SSO is that devices must be domain-joined via on-prem AD. It is not used on Azure AD joined or Hybrid AD joined devices.  

 
Figure 3 – Seamless Single Sign-On Source: Azure Active Directory Seamless Single Sign-On

Figure 3 – Seamless Single Sign-On
Source:
Azure Active Directory Seamless Single Sign-On

 

Otherwise, seamless SSO is pretty straightforward to deploy and implement. You don’t require additional on-prem infrastructure or services to make this work and the user experience is improved because users automatically sign into both on-prem and cloud-enabled services (hence the name, right???).  

Additional information about Seamless SSO can be found here

Lastly, let’s talk about the monstrosity of complexity that is ADFS. Okay that seemed a little dramatic but when you look at the comparison, ADFS is certainly the most complicated of the authentication options, and for good reason too. ADFS is used to federate identity and authentication with other services. ADFS requires the use of on-prem technology services running the ADFS services in Windows Server (2012 R2 or higher) to connect an existing ADFS farm with Azure AD connect. This allows a federation trust to be established between ADFS and Azure AD so users (internally or externally) can sign-in to both on-prem our cloud-enabled services.  

Now ADFS has some significant design considerations that are too much to break down here. However, if you want to know more about ADFS you can check out the design article here

 
Figure 4 – Active Directory Federated Services (ADFS) Source: Azure AD Connect user sign-in options

Figure 4 – Active Directory Federated Services (ADFS)
Source:
Azure AD Connect user sign-in options

 

For the purpose of the MS-100, you need to know a few things about ADFS:  

  1. If you’re using a peripheral device-based MFA (i.e. biometric readers or smart cards). Your likely looking at a federated authentication option through a hybrid identity method of authentication. 

  2. ADFS is the most complex authentication option when compared to PTA or PHS. Most cases the least complex option is PHS (remember this is the default option) 

  3. A web application proxy (WAP) server is needed on the perimeter network to establish a federated authentication option using ADFS. 

If you want to expose yourself to material that is going to help you study and prepare for the exam, I highly recommend you take a look at the MS-100 Certification Course: M365 Identity and Services through Skylines Academy. There you’ll get exposed to 18 different modules on topics covered on the exam. 

Please don’t hesitate to reach out to Skylines Academy should you have any questions about your study needs for your next M365 examination! Thanks for your time, stay healthy out there, and happy studying to all!!!! 

David Hood

 
davidhood.jpg

About the Author

David Hood is a Technical Account Manager for Microsoft Corporation where he supports enterprise education customers across a 4 state territory. Prior to that he spent the past 8 years as a Solutions/Enterprise architect supporting and designing solutions for regulated industries like the utility industry and the Department of Defense Intelligence Community. David also teaches Information Technology curriculum at Lindenwood University as an Adjunct Instructor. He also develops coursework for the University when needed as well. . Feel free to connect with David on LinkedIn or Twitter where he shares information regarding technology and education.

 
Previous
Previous

AZ900: Azure Regions

Next
Next

Azure Security Part 3: Security Center Alerts and Automation workflows