Recognizing the right implementation for hybrid identity authentication can be difficult. If you are finally ready to adopt a cloud architecture, choosing how authentication will occur will be one of your first decisions. Alternatively, if you moved to the cloud several years ago, it might be worth a second look at what is available and why it might be time for a change. This is especially true for environments using Active Directory Federation Services (AD FS) as Microsoft now recommends migrating to Entra ID.
In this post, I will break down the different hybrid identity authentication options available today and the advantages and disadvantages of each.
A brief history of Active Directory Federation Services
Active Directory Federation Services (AD FS) predates hybrid identity authentication and the “cloud” itself. It began as Microsoft’s solution for single sign-on and to establish trust across organizations. This early implementation of federated identity has gone through multiple iterations over the years. It’s no surprise that organizations that have invested in AD FS continue to upgrade and expand its footprint. Designing an AD FS architecture requires deploying multiple servers and services. It relies upon implementation of network load balancers, firewall rules and DNS.
So why might you stay with, or implement, AD FS? Using Microsoft’s decision tree, a sign-in requirement not natively supported by Entra ID is the main reason to use federated authentication. Advanced configurations such as using a third-party authentication solution, multi-site on-premises authentication or using an attribute other than UPN for sign in may require the use of federation. Environments with considerable investments in an existing federation may also choose to stay. However, for most environments, one of the other two cloud authentication solutions are superior in many ways.
Introducing cloud identity authentication
In terms of Microsoft services, cloud authentication simply means that Entra ID handles authentication. Cloud authentication comes in two flavors, password hash synchronization (PHS) and pass-through authentication (PTA).
Microsoft Entra PHS creates a connection between on-premises Active Directory (AD) and the Entra tenant. This solution synchronizes identities, allowing users to use the same credentials in the cloud that they do on-premises. Microsoft Entra PTA also allows users to use the same credentials in the cloud that they do on-premises, but instead of synchronizing data, password validation occurs against the on-premises Active Directory. This method relies upon agents installed on servers in the authenticating forest.
Advantages and disadvantages of cloud identity authentication
Password Hash Sync (PHS)
Microsoft Entra Password Hash Sync seems to be Microsoft’s favorite solution for authentication and is typically the default choice unless specific requirements rely upon another solution. Even if another authentication solution is in place, PHS can run alongside, acting as a backup. Because of this, PHS is the most commonly deployed solution. It also requires the least effort to deploy and maintain.
In terms of authentication, it doesn’t get much more redundant than PHS. Because authentication happens in Entra ID, it scales to all Microsoft data centers. High availability does however begin to break down when speaking of the synchronization service itself. Microsoft Entra Connect does not support an active-active infrastructure and instead relies upon a secondary server in a standby configuration. Microsoft Entra Cloud Sync, released in 2021, added support for multiple sync agents.
There are other possible problems around synchronization. PHS uses two different sync cycles. The password hash portion runs every two minutes. This means that depending on when the password change occurs, it could take up to two minutes before the new password is reflected in Entra ID. The remaining (supported) user attributes synchronize every 30 minutes. The ‘enabled’ attribute is specifically concerning because it means that decommissioning could take several minutes before flowing into Entra ID.
Other password-related items are not natively supported when using PHS. This includes a password expiration policy (from Group Policy or Fine-Grained Password Policy), the “User must change password at next logon” account flag, account expiration date, and accounts in a locked-out state. Depending on the specific use case for an environment, Microsoft offers solutions for each of these scenarios. But if using on-premises user-level AD policies are a requirement, then PTA might be a better solution.
Pass Through Authentication (PTA)
Microsoft Entra Pass Through Authentication is a good solution when Entra ID must adhere to on-premises components such as account expiration, account lockout or logon hours. Getting started with PTA is fairly simple as it only requires lightweight agents to be installed on existing servers with access to domain controllers. PTA solves the problems that PHS has with synchronization delays and attribute availability but loses the benefit of high availability as it relies on access to the internal network.
Availability problems are partially mitigated by deploying multiple authentication agents across multiple sites. Although it may not seem to make sense, PTA actually occurs in the cloud after a secure password verification with one of the on-premises authentication agents. Before panic ensues with the idea of presenting network access to the cloud, authentication agents initiate communication over HTTPS to the Entra ID tenant. This means that only outbound firewall rules are required. When a user tries to log in to an Entra application, the authentication attempt is placed in a queue where one of the available authentication agents retrieves and validates the request.
Beyond on-premises outage survival and network connectivity concerns, PTA does have a few unsupported scenarios. Support for PTA is not currently available using Microsoft Entra Cloud Sync, so environments must use Microsoft Entra Connect. It also does not work with Microsoft Entra Domain Services or temporary/expired passwords when signing into a Microsoft Entra joined device. As mentioned previously, PHS can be deployed as a secondary authentication option and is an acceptable workaround for these unsupported scenarios.
User protections and enhancements
Another major benefit of utilizing PHS (even as a backup) is the use of Identity Protection, specifically leaked credential reports. Information gathered from these reports allows a tenant to block logins or force password changes for users with leaked credentials. Another great security benefit of Entra ID that integrates with both PTA and PHS is smart lockout. Smart lockout separates valid end user sign-in attempts from those that may originate from adversaries and treats them differently.
Another fun buzzword when speaking of cloud authentication is ‘single sign-on’ (SSO). This phrase means different things in different contexts. In terms of Microsoft cloud authentication, SSO means that logging into a company device with company credentials only needs to occur once. Without this additional feature, authentication must occur once when logging into the device itself (logon screen) and again when logging into a cloud application (browser).
Environments running all modern Operating Systems (OS) that are registered with Microsoft Entra ID or Microsoft Entra hybrid joined may take advantage of primary refresh tokens (PRT) for SSO. Most environments cannot fully rely on the PRT so Microsoft Entra seamless SSO must be deployed in the environment. SSO works with both cloud authentication options, PHS and PTA.
Security Considerations with identity authentication
Many of the security concerns for PHS or PTA surround Microsoft Entra Connect. This service plays a critical role in synchronizing identities, from on-premises to Entra ID. Most importantly, the server and user account running Microsoft Entra Connect must be treated as control plane (Tier 0) assets. The server should be protected like a domain controller with rights limited only to Domain Admins. The user account (typically MSOL_###) should also be protected and monitored due to the permissions it’s delegated during deployment. In addition, the software version of Microsoft Entra Connect should be current. A full list of Microsoft hardening guidance can be found here.
Storing hashed passwords
The most common concern with PHS is storing hashed passwords in the cloud. Microsoft has put multiple safeguards in place that address this concern. Not even the password hash synchronization agent has access to clear text passwords. The use of several hashing algorithms results in a password that is hashed with MD4+salt+PBKDF2+HMAC-SHA256. Nathan McNulty, senior security solutions architect, explains it in an easily digestible manner below.
While the hash itself might not be a serious concern, there are some best practices surrounding the synchronization process itself that must be evaluated.
Matching existing accounts
One commonly overlooked component of account synchronization is how matching existing objects occurs. When tying two accounts together, there must be a set of rules that indicate the objects belong to the same identity. Microsoft Entra Connect allows what they call soft matching and hard matching. Having either of these methods enabled introduces security risks. These settings are found and changed using Microsoft Graph PowerShell.
The value of “BlockCloudObjectTakeoverThroughHardMatchEnabled” and “BlockSoftMatchEnabled” are the two attributes that control this feature.
Cloud administration
When configuring synchronization, it’s important that sensitive objects are filtered so they do not appear in Microsoft Entra ID. Filtering can be configured at any time and there are multiple options available to restrict objects based on Domain, OU, attribute and group. A common example of using filtering would be to prevent the synchronization of dedicated on-premises administrative accounts. Microsoft recommends dedicated accounts for cloud administration.
Microsoft Entra ID accounts that are members of highly privileged roles (such as Global Administrator) should be cloud-only. By default, these accounts are created using the “onmicrosoft.com” user principal name (UPN). It should also be understood that all accounts, especially those granted elevated access, need to use MFA.
On-premises protections
When using PTA, the same best practices around using separate accounts apply. One additional concern with PTA is protecting the servers with the Authentication Agent installed. Similar to protecting the Entra Connect server, these servers also must be treated as control plane (Tier 0) assets. For more information on attack strategies against Entra ID, Adam Chester wrote a highly praised article that covers the attacks that these best practices attempt to mitigate.
Reduce your AD attack surface.
The use of Seamless SSO comes with its own recommended protections. When Seamless SSO is enabled, a computer account (AZUREADSSOACC) is created in the on-premises AD. Unlike the Entra Connect or Authentication Agent servers, this computer object does not actually have an OS installed, but it still requires all the same protections. This account shares the Kerberos decryption key with Entra ID to maintain connectivity. Microsoft recommends this decryption key is changed every 30 days and utilizes AES encryption.
AD FS hardening recommendations don’t deviate much from the protections already discussed regarding on-premises servers. These servers are typically more numerous and complex in nature, as there are network load balancing considerations and protections associated with managing proxy servers in a DMZ. Additional considerations are settings around certificates, service accounts, logging and monitoring. Microsoft Entra customers can make use of the Entra Connect Health agent to assist with these.
Conclusion
When it comes to hybrid identity, there is no one-size-fits-all solution for authentication. Institutional preference, environmental constraints and compliance requirements all play a crucial role. Modern technologies available make this an ideal situation, as most companies are able to build a hybrid solution to support hybrid identity.
The benefits of PHS far outweigh the risks. Its ability to be deployed alongside either of the other two options makes it flexible to use. PHS can simply deliver leaked credential reports, it can be implemented for only a subset of users and can provide on-premises outage survival. Microsoft states there are two categories that organizations fall into when responding to a cyberattack: organizations who enabled PHS as a backup could be back online in a matter of hours, whereas organizations without PHS were offline for weeks.
