I’ve seen a lot of confusion around this feature, and some people pointing at it as a weak point in identity security because they believe the synchronised content can be intercepted, replayed, or otherwise compromised. I’m here to say, this is not the case at all. I’m going to make this blog post really short: Is Password Hash Sync (PHS) safe? The simple answer is yes. But please don’t stop reading yet, let me explain how this works so that you can help fight the misinformation and fear surrounding this awesome feature.
The best way to explain what Password Hash Sync (PHS) is, is to start by describing what it absolutely isn’t:
- PHS is not your password. Even if captured or breached, you can’t paste this into a sign-in prompt.
- PHS is not able to be reversed to uncover what your password is. It’s a one-way cryptographic hash.
- PHS is not a a valid on-premises hash, so it can’t be intercepted and used on-premises.
- PHS is not able to read/access your password, at any time during the sync process.
So what exactly is a password hash then?
Put simply, a hash value is a result of a one-way mathematical function. Hash functions are mostly used to determine if two objects are equal, and an example of this might be comparing published checksums when downloading a large amount of data to ensure that the download completed without errors or tampering. Producing a usable hash value requires that the hash function performs the following tasks:
- It must be fast to compute, and fast to compare.
- It must minimize duplication of output values (collisions) to ensure that values are as unique as possible.
- It must successfully scramble the bits of the key so that the value cannot be reversed.
- It must convert variable length keys into fixed length values using a parity-preserving operators like ADD or XOR.
Importantly, while many think the process of hashing passwords and sharing the hashes is insecure, this is actually how passwords already work within the Active Directory Domain Service, and the fact that PHS adds additional hashing processes to this means that the result of PHS is at least as secure as an on-premises password hash. But let’s dig into this in a little more detail. Internally, Windows represents passwords as 256-character UNICODE strings, and these password values are represented by MD4 hashes and stored as the ‘NT hash’. When a user logs on, the password the user types in to the secure login window is converted by the one-way function and held in memory by the Local Security Authority Subsystem Service (LSASS) process. If the user is authenticating against an Active Directory domain, the NT hash is used in a Kerberos logon against the Key Distribution Center (KDC), which is typically the Domain Controller. If the hash can be verified, and by that we mean match and perform a valid Kerberos authentication process, the user is signed on.
When the Password Hash Sync (PHS) feature is enabled, what you are actually doing is authorising the Azure AD Connect service account to read existing hashes from Active Directory, allowing the service to improve the hash security by implementing a per-user salt – which is the process of hardening hashes using another key attribute known only to the hashing and authentication versification systems – and performing 1,000 iterations of the more secure HMAC-SHA256 key hashing algorithm. What PHS actually synchronises, is the result of this complex process to Azure Active Directory (Azure AD). Again, at no point is the plain-text version of your password read or otherwise exposed to the password hash synchronisation feature, to Azure AD, or any of the associated services. And again, this hash can only be used to verify against when using Azure-based logons. In short, A PHS object is a more secure hash of the original AD hash used for on-premises authentication.
How are passwords kept in sync?
So far we’re talked about what Password Hash Sync is, and isn’t… but how does it actually work? The ‘flow’ of password hash synchronisation is almost the same as the regular synchronisation of user data: Scheduled full and delta syncs, managed by the server that is running Azure AD Connect. The difference is, however, that passwords are obviously synchronised more frequently than the standard directory sync window for other attributes.. because we’re talking about the ability to authenticate. While the documentation says that password hash synchronization runs every two (2) minutes, we are typically seeing password updates – which require the Password Hash Sync process to complete as well – take under one (1) minute, and usually a matter of seconds.
After enabling Password Hash Sync in the Azure AD Connect options, a full initial synchronisation is performed for all of the included users in the scope. If you have performed a custom installation of Azure AD Connect, then only the user objects in the selected OUs will be selected for the PHS process, otherwise all users in the Forrest may be selected if the Express option was used during setup. When you synchronise a password, it overwrites the existing cloud password, so depending on how your environment was configured, you may need to inform users that their logon experience may change. After the initial sync has been completed, and you change an on-premises password (including via Password Write-Back functionality), the updated password is immediately scheduled for synchronisation. The password hash synchronisation feature automatically retries failed synchronization attempts, so if an error occurs during an attempt, an error is logged in your event viewer and the task will try again.
IMPORTANT: The synchronisation of a password has no immediate impact on the user who is currently signed in, unless they initiated the password reset from their end. For all users, the current ‘cloud service session’ is not immediately affected by a synchronised password change while signed in, however, when the cloud service requires you to authenticate again, you need to provide the new password.
What are the benefits of Password Hash Sync?
Aside from enabling Hybrid identity and Single Sign-On, Password Hash Sync also brings a number of beneficial features to your environment. Here are just a few of the benefits:
- Microsoft Leaked Credentials Service
Microsoft uses information from security researchers, law enforcement and the Microsoft Security team to identify breached websites and leaked credentials, including those added to online groups, hacking sites, the Dark Web, and more. Microsoft then acquires username/password pairs from these sources and passes them through the same hashing algorithm as Azure AD users’ password hashes use, and these are then checked against all users to help identify any bad or compromised password. When a match is found (indicating a compromised credential), a ‘Leaked Credentials Risk Event’ is created. This, alone, should be enough for sites to seriously consider enabling PHS. - Cloud Authentication
With PHS enabled, your users gain the ability to authenticate using Azure AD for most functions, and aren’t required to redirect to an Identity Provider (IdP) such as Active Directory Federated Services (AD FS). If you’ve been following my blog on JAMF Connect, this was the feature we used to remove the complex Hybrid configuration and allow users to authenticate directly with Azure AD as if they were native cloud identities. - Smart Lockout
Bad actors will eventually target your tenant, attempting to brute force passwords. Smart Lockout tracks failed attempts at logging into an account – remembering the last three (3) bad password hashes to avoid re-incrementing the lockout counter by accident – and locks the account from sign-in attempts for one (1) minute after ten failed attempts. It might not seem like much, but when your attacker is likely using a dictionary with millions of passwords, a minute delay between each ten adds up to quite a lengthy period they’d need to persist with… and most won’t bother. - IP Lockout
Similar to Smart Lockout above, IP Lockout works by analysing billions of sign-ins across Microsoft 365 to assess the traffic from each IP address, looking for IP addresses acting maliciously, such as those password spraying the tenant. When a malicious IP is identified, this feature will blocks those sign-ins in real-time, while allowing the real user to continue to successfully sign in. - DDoS Prevention
While not often listed as a feature, PHS helps protect you on-premises authentication system. Should your tenant experience a Denial of Service (DoS) and/or Password Spray attack, Microsoft will actually take the brunt of that traffic. With PHS enabled, user accounts gain the ability to authenticate against the cloud without being immediately redirected to your on-premises Active Directory Federated Services (AD FS). - Fallback Authentication Method
Another important benefit of PHS, is that when authentication happens via an Identity Platform (IdP) like on-premises AD FS, your server and infrastructure is responsible for managing the load and potentially causing downtime. With PHS already in place, you are able to follow a wizard in the Azure AD Connect settings to quickly switch over to Azure AD authentication in case of a Disaster Recovery situation.
Webber Zone 
You must be logged in to post a comment.