Jul 24, 2023
Password hash synchronization– Planning Identity Synchronization
Password hash synchronization (commonly referred to as PHS) is the Microsoft-recommended identity solution. In addition to synchronizing the core identity object data, PHS also synchronizes password hash values to the account objects in Azure AD. This ensures that users can use the same password to access local Active Directory resources, as well as Azure AD services.
Further reading
The security behind Azure AD Password Hash Synchronization is complex, involving multiple hashing algorithms. For a deeper understanding of how Password Hash Synchronization protects user data, see https://learn.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-password-hash-synchronization.
When a user logs in to a tenant that has PHS configured, every part of the authentication takes place in Azure AD. This is advantageous because the organization has no reliance on the availability of any on-premises infrastructure for ongoing authentication. Once an identity and its password hash have been synchronized, the on-premises directory isn’t needed until the on-premises object is updated again (such as an additional email address, a change in the display name, or a new password).
In addition, PHS enables an advanced Azure AD Premium P2 security feature: leaked credential detection. With this feature, Microsoft continuously checks various dark websites for organizational identity data that may have been compromised.
As mentioned in the Accounts and security section, password hash synchronization requires the service account to have the Replicating Directory Changes and Replicating Directory Changes All rights in the on-premises directory.
Password hash synchronization is a cloud authentication solution.
Pass-through authentication
Similar to password hash synchronization, pass-through authentication (PTA) relies on synchronizing objects to Azure AD. Unlike PHS, however, the actual password validation happens on-premises. PTA relies upon an agent installed on-premises, which periodically checks Azure for an authentication request.
When Azure AD Connect is configured with PTA, a secure channel is established between the Azure Service Bus and the lightweight PTA agent. For redundancy, you can deploy multiple PTA agents in your environment.
Note
From a networking perspective, Azure AD Connect’s communication is outbound only to the Azure Service Bus. Unlike federation, PTA does not require inbound connectivity.
When a user requests access to an Azure AD resource, the logon request is stored on the Azure Service Bus. This request is encrypted with the public key of each of the PTA agents. The agents check the Service Bus for a request, bring the request back on-premises, decrypt it with the agent’s private key, and then process the request against an on-premises domain controller. The result of the validation (either success or failure) is then sent back to the Azure Service Bus, where Azure AD retrieves the response and then either grants or denies the logon request.
PTA is a potential solution for organizations that want as much benefit from cloud authentication as possible but may have organizational requirements for on-premises credential validation or the enforcement of Active Directory logon hours.
Due to its on-premises password validation component, if none of the on-premises authentication agents can connect to both the Azure Service Bus and local Active Directory, users will be unable to log in.
Microsoft categorized PTA as a cloud authentication solution.
More Details