This post is part of the overall MS-500 Exam Study Guide. Links to each topic as they are posted can be found here

For this section of the study guide, we will look at how to plan Azure AD authentication. There are multiple ways to process authentication in Azure AD / Microsoft 365. In order to choose the right option for your environment, we need to understand the benefits and drawbacks associated with each.

The below diagram from the Microsoft documentation represents at a high level the decisions that we need to make and which mechanism is best for each use case.

Lets dive into each option separately so we understand the reasoning behind the decisions.

Password Hash Synchronization

Password Hash Synchronization leverages Azure AD Connect (more on that in a future topic) to synchronize a hashed value of user passwords to Azure AD from our local directory. It’s important to understand that we never synchronize any “plain text” passwords, instead (at a very high level) the value stored in AD is encrypted with a Hash value, this is then synchronized to Azure AD. When our user logs in to Microsoft 365, their password is subject to the same hashing mechanism and the output is validated to sign the user in.

Some key things to remember about Password Hash Synchronization:

• Authentication is handled by Azure AD, not the local directory
• Provides Same Sign-On for users where Username and Password match their local account. This is different from Single Sign-On which is available through Seamless SSO and Federation
• Can be combined with Seamless SSO to provide Single Sign-On
• Passwords are synchronized from on-premises via AD Connect. A password change may not be reflected in Microsoft 365 / Azure AD immediately, relying on the synchronization to occur (every two minutes) before Azure AD is aware of the new value
• Account status is also subject to synchronization cycles although regular synchronization does not occur as often as password sync – This is configurable and the default is 30 minutes
• Password Expired and Account Locked states from local AD are not Synchronized to Azure AD
• As there is no requirement for on-premises authentication, Password Hash Synchronization allows for High Availability and Business Continuity of the Microsoft 365 service even in the event that AD Connect, Domain Controllers or even entire on-premises domain becomes unavailable
• Password Hash Synchronization can be enabled even if another method of authentication is used, this allows for a quick switchover in the event the primary method of authentication becomes unavailable, such as an ADFS farm going down

Pass-Through Authentication

Pass-Through Authentication (PTA) leverages one or more on-premises PTA agents to process authentication for users. When a user authenticates to Azure AD, the users sign in data is stored in a “queue”, this queue is polled by the on-premises PTA agents and processed against the on-premises Domain Controller when an authentication request is found. This structure means that we don’t need to open any inbound firewall ports, all connections for PTA are outbound. Authentication is handled by our local Directory Services.

Some key points for Pass-Through Authentication:

• Authentication is handled by on-premises Active Directory
• The first PTA agent is always installed on our AD Connect server
• Additional Agents can be installed, authentication will be processed by whichever agents detects the sign-in request first, providing high availability
• PTA does not require any inbound ports, the Agents require HTTP/S outbound to particular Microsoft endpoints
• Provides Same Sign-On for users where Username and Password match their local account. This is different from Single Sign-On which is available through Seamless SSO and Federation
• PTA alone never stores any user password data in the Cloud
• Password Hash Synchronization can be enabled with PTA, in the event of an issue with PTA agents, an admin can quickly switch off PTA and allow sign-in using Password Hash
• As authentication happens on-premises, account lockouts and password expiration are checked during the sign-in process
• Up to 40 PTA authentication agents can be installed in your on-premises domain
• PTA agents require Windows Server 2012 R2 or later and TLS 1.2

Federation

Federation for Azure AD allows us to leverage Active Directory Federation Services (or PingFederate) to set up a “federation trust” between our Azure AD tenancy and our On-Premises Active Directory. User sign-in requests are redirected from our Azure AD tenancy, back to our on-premises federation endpoint. In a typical ADFS topology, this would be our Web Application Proxy servers for external connections and our ADFS servers for anyone connecting from our internal network. ADFS in itself is a massive topic but here we will look at the relevant aspects for the Microsoft 365 Certification.

A typical ADFS topology would consist of a minimum of two ADFS servers on the internal domain network and two Web Application Proxy servers in a DMZ network which forward authentication requests from the internet (Extranet) to our ADFS servers. With ADFS 2019, we have the following authentication options:

ADFS also provides a lot of flexibility around how our authentication is processed. We can customize our authentication methods and our Forms Authentication screens. For the Intranet zone (local domain network) we can provide single sign-on through Integrated Windows Authentication, removing all authentication prompts from our users, we can also simplify and secure login by using Certificate or Device authentication. Integration with Azure MFA can also be performed directly by ADFS to provide MFA to non-Azure AD services.

ADFS can be configured for Office 365 directly from the AD Connect Wizard so in depth knowledge of ADFS claims rules and reliant party trusts is not a requirement to set up, although it is something that you should understand to troubleshoot and maintain an ADFS environment.

Key points to know about Federated Authentication:

• Authentication is handled by the On-Premises directory, proxied through ADFS
• A minimum of two ADFS and two Web Application Proxy servers are recommended for allow for HA
• ADFS does require inbound ports for user authentication. Inbound HTTPS to the Web Application Proxy servers from the internet is required to service authentication requests. HTTPS is also required from the Web Application Proxy to the ADFS servers
• ADFS is highly customizable with an array of authentication mechanisms
• ADFS can provide Single Sign-On using the right authentication mechanisms
• ADFS can differentiate between authentication requests coming from the “Intranet” zone and the “Extranet” zone and treat them differently
• ADFS authentication is enabled per domain
• ADFS is not possible for the default tenant (onmicrosoft.com) domain
• Staged rollout of Cloud Authentication for Federated Domains is available in Preview currently
• ADFS can be configured directly from AD Connect for both new and existing ADFS farms
• Password Hash Synchronization can be enabled along with ADFS, in the event of an issue with ADFS, an admin can quickly switch off PTA and allow sign-in using Password Hash
• When deploying Federation, it is important to keep at least one “break glass” admin account on a non-federated domain such as the tenancy domain. If there is an extended issue with ADFS, Admins will need to log in to disable federation, this won’t be possible without an account on a non-federated domain. As a side note, this is good practice for all security features such as Conditional Access etc.
• ADFS can be useful to consolidate user experience when you have other services using ADFS for authentication

Seamless Single Sign-On

While Seamless SSO on it’s own cannot be used as a primary authentication mechanism, it can be layered on top of the Password Hash Sync or PTA to fill the gap around Single Sign-On. Seamless SSO works when the authentication request comes from an On-Premises Domain Joined Machine only. When configured (through AD Connect), Seamless SSO manages authentication by verifying that the user is signed on to the local Active Directory Domain. AD Connect provisions a computer account in the local directory, the decryption key of this computer account is synchronized to Azure AD.

During authentication, Azure AD will request an Active Directory Kerberos ticket from the local machine, this is then encrypted and provided from Active Directory to the local machine on behalf of the user without any input required. The encrypted ticket is then passed to Azure AD, which can decrypt the ticket for validation and authentication to take place.

All of this takes place in a few seconds, with the result being that the user, if valid, is authenticated seamlessly and gains access to Azure AD / Microsoft 365. If this process fails, the users authentication prompt will fall back to either Password Hash or PTA depending on which is in use.

Key Points on Seamless SSO:

• Seamless SSO is not a primary authentication mechanism, PTA or Password Hash are required
• Not compatible with ADFS, however ADFS can provide Single Sign-On natively itself
• Seamless SSO is “opportunistic” meaning that if it fails, the user authentication will not be rejected and will fail back to whatever mechanism is in place
• Seamless SSO is configured via AD Connect however there are Computer level settings such as site zone mapping which can be pushed via GPO
• Can be used to seamlessly Hybrid Azure AD Join Domain Computers
• The Kerberos decryption key is created by provisioning a computer account named AZUREADSSO in the local Active Directory, this key is synced to Azure AD
• For security reasons it’s important to frequently roll over the decryption key, this is recommended at least every 30 days and can be done via PowerShell

Summary

Hopefully you now have enough information to decide on the best authentication option for your deployment. I’ve included some useful links below that I recommend checking out:

What is hybrid identity with Azure Active Directory? | Microsoft Docs

Four steps to a strong identity foundation – Azure AD | Microsoft Docs

Authentication for Azure AD hybrid identity solutions – Active Directory | Microsoft Docs

What is password hash synchronization with Azure AD? | Microsoft Docs

Azure AD Connect: Pass-through Authentication | Microsoft Docs

What is federation with Azure AD? | Microsoft Docs

Azure AD Connect: Seamless Single Sign-On | Microsoft Docs

Azure AD Connect: Seamless Single Sign-On – quickstart | Microsoft Docs