Examine authentication options for the hybrid identity model
- 9 minutes
The hybrid identity model enables organizations to synchronize their on-premises Active Directory objects and attributes to the cloud-based Microsoft Entra ID. Organizations utilizing a hybrid model use directory synchronization to manage the identities in their Active Directory Domain Services (AD DS). Directory synchronization also synchronizes all updates to user accounts, groups, and contacts to the Microsoft Entra tenant of their Microsoft 365 subscriptions.
Note
When directory synchronization synchronizes AD DS user accounts for the first time, it doesn't automatically assign them a Microsoft 365 license, and they can't access Microsoft 365 services, such as email. Organizations must first assign them a usage location. They must then assign a license to these user accounts, either individually or dynamically through group membership.
Organizations can choose from the following authentication types when using the hybrid identity model:
- Managed authentication. Microsoft Entra ID handles the authentication process. It either uses a locally stored hashed version of the password, or it sends the credentials to an on-premises software agent that authenticates them using the on-premises AD DS.
- Federated authentication. Microsoft Entra ID redirects the client computer requesting authentication to another identity provider.
The following sections examine these two types of authentication in greater detail.
Managed authentication
There are two types of managed authentication:
- Password hash synchronization (PHS). With PHS, Microsoft Entra ID performs the authentication itself. PHS enables users to use the same username and password that they use on-premises.
- Pass-through authentication (PTA). With PTA, Microsoft Entra ID has AD DS perform the authentication. 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.
Additional reading. For more information, see Choosing the right authentication method.
Password hash synchronization (PHS)
With PHS, organizations synchronize their AD DS user accounts with Microsoft 365, and they manage their users on-premises. Organizations don't have to deploy any extra infrastructure besides Microsoft Entra Connect Sync or Microsoft Entra Cloud Sync.
PHS uses a secure, one-way hash synchronization process to protect the user's password. The password hash is encrypted during transmission and stored securely in Microsoft Entra ID, which uses the hash for authentication purposes.
Important
PHS never sends or stores the actual password in Microsoft Entra ID, which helps protect against password-related attacks.
PHS provides several benefits, including:
- The ability to use on-premises passwords for cloud-based services.
- A reduction in the number of passwords that users must remember.
- The ability to enforce on-premises password policies in the cloud.
When users change or reset passwords on-premises, PHS synchronizes the new password hashes to Microsoft Entra ID. By doing so, users can always use the same password for cloud resources and on-premises resources. PHS never sends user passwords to Microsoft Entra ID, nor does it store them in Microsoft Entra ID in clear text. Some premium features of Microsoft Entra ID, such as Identity Protection, require PHS regardless of which authentication method an organization uses.
Pass-through authentication (PTA)
PTA provides a simple password validation for Microsoft Entra authentication services. It authenticates users by validating their on-premises Active Directory credentials against a lightweight software agent running on one or more on-premises servers. This process validates the users directly with your AD DS. With PTA, you synchronize AD DS user accounts with Microsoft 365 and manage your users on-premises.
When an organization enables PTA, it redirects users to the PTA agent to authenticate their credentials. The agent validates the user's credentials against the on-premises Active Directory and returns the authentication results to Microsoft 365.
Important
PTA never sends or stores passwords in Microsoft 365, which helps protect against password-related attacks.
PTA supports a range of authentication scenarios, including:
- Password-based authentication
- Smart card authentication
- Other forms of multifactor authentication
PTA also provides many advanced features, including the ability to:
- Exclude specific users or groups from authentication.
- Specify a custom port for the PTA agent.
- Configure failover to other authentication methods if a failure occurs.
PTA provides several benefits, including:
- The ability to use on-premises passwords for cloud-based services.
- A reduction in the number of passwords that users need to remember.
- The ability to enforce on-premises password policies in the cloud.
Caution
The lightweight agent that PTA requires organizations to install and maintain on-premises might not be suitable for all organizations or authentication scenarios.
PTA allows an organization’s users to sign into both on-premises and Microsoft 365 resources and applications using their on-premises account and password. This configuration validates the users’ passwords directly against the organization’s on-premises AD DS without storing password hashes in Microsoft Entra ID.
Microsoft designed PTA for organizations with a security requirement to immediately enforce on-premises user account states, password policies, and sign-in hours.
Federated authentication
When you choose this authentication method, Microsoft Entra ID hands off the authentication process to a separate trusted authentication system to validate the user's sign-in. Federated authentication is primarily for large enterprise organizations with more complex authentication requirements. It synchronizes AD DS identities with Microsoft 365. It also requires that organizations manage their user accounts on-premises. With federated authentication, a user has the same password on-premises and in the cloud. As such, they don't have to sign in again to use Microsoft 365.
Federation authentication in Microsoft 365 can use Active Directory Federation Services (AD FS) or a third-party federation system to validate user sign-in. AD FS is a Microsoft service that provides single sign-on (SSO) and identity federation capabilities. AD FS allows users to authenticate using their on-premises Active Directory credentials and access resources in cloud or partner environments without the need for separate identities or credentials.
AD FS uses the Security Assertion Markup Language (SAML) and other protocols to securely exchange authentication and authorization data between different organizations. It can enable SSO with a wide range of applications and services that support SAML or other federation standards.
Using AD FS for federation authentication with Microsoft 365 provides several benefits, including:
- The ability to use on-premises Active Directory to authenticate users.
- Single Sign-on (SSO) to multiple cloud applications.
- Support for multifactor authentication (MFA) and conditional access policies.
The original federated authentication process
Microsoft originally designed federated authentication so that when a user attempted to access a Microsoft 365 resource, the request first went to a federation proxy server. The federation proxy server then redirected the user to the appropriate identity provider for authentication. The identity provider was either an on-premises AD FS server or a third-party identity provider that supported Security Assertion Markup Language (SAML) or OpenID Connect (OIDC).
Once the identity provider authenticated the user, it sent a security token back to the federation proxy server, which in turn sent it to Microsoft 365. Microsoft 365 then used the security token to authorize the user and grant access to the requested resource.
The federation proxy server acted as an intermediary between the user, the identity provider, and Microsoft 365. It helped to ensure the authentication process was secure, and that transmission didn't compromise user credentials. Additionally, the federation proxy server could provide load balancing and failover capabilities for high availability and scalability of the authentication process.
Replacing the federation proxy server with a web application proxy
A new Remote Access role service called Web Application Proxy (WAP) took on the role of the federation server proxy starting with Windows Server 2012 R2. In legacy versions of AD FS (such as AD FS 2.0 and AD FS in Windows Server 2012), the federation server proxy enabled AD FS for accessibility from outside the corporate network. To provide the same feature in Windows Server 2012 R2 and later, organizations can deploy one or more web application proxies.
In the context of AD FS, Web Application Proxy functions as an AD FS federation server proxy. WAP also provides reverse proxy functionality for web applications inside an organization's corporate network. This design enables users on any device to access them from outside the corporate network.
Overall, the Web Application Proxy server provides a more flexible and scalable solution for secure remote access to web applications compared to the older federation proxy server. It also provides the following new features and improvements:
- Better support for modern authentication protocols. WAP supports newer authentication protocols such as OAuth and OpenID Connect in addition to the traditional SAML-based protocols. This feature enables organizations to provide access to modern web applications that require these protocols for authentication.
- Improved application publishing capabilities. WAP provides more flexible options for publishing applications to the internet, including preauthentication and pass-through authentication. This feature enables organizations to secure access to their applications and better control access based on user identity.
- Support for additional protocols. WAP supports other protocols such as HTTP and HTTPS besides the traditional SAML and WS-Federation protocols. This feature makes it easier to provide secure remote access to a wider range of applications.
- Integration with Microsoft Entra ID. Organizations can integrate WAP with Microsoft Entra ID to provide a cloud-based authentication and authorization solution. This feature makes it easier to provide secure access to cloud-based applications and resources.
- Improved scalability and performance. WAP provides improved scalability and performance compared to the older federated proxy server. It can handle a larger number of requests and provide better response times, making it better suited for larger organizations with higher traffic requirements.
Third-party authentication and identity providers
Besides AD FS, Microsoft 365 supports federation with other identity providers such as Microsoft Entra ID, PingFederate, Okta, and other third-party identity providers that support the SAML or WS-Federation protocols. As such, organizations can use their on-premises AD FS infrastructure or a third-party identity provider to authenticate their users for Microsoft 365 services.
Third-party authentication and identity providers can synchronize on-premises directory objects to Microsoft 365 and to cloud resource access primarily managed by a third-party identity provider. If an organization uses a third-party federation solution, it can configure sign-on with that solution for Microsoft 365 provided the third-party federation solution is compatible with Microsoft Entra ID.
Additional reading. For more information, see the Microsoft Entra ID federation compatibility list.
Administration
Because an organization stores original and authoritative user accounts in the on-premises AD DS, it must manage its identities with the same tools that it uses to manage its AD DS.
Organizations can't manage synchronized user accounts in Microsoft Entra ID using the Microsoft 365 admin center or PowerShell.
Knowledge check
Choose the best response for the following question.