Now that businesses are adopting cloud computing as part of their business model, a large percentage are choosing to connect their on-premises Active Directory environment to its counterpart in the cloud, Microsoft’s Azure Active Directory. When you extend your on-premises AD to Azure AD, you have two choices for how you want on-premises users to authenticate to the cloud service: identity federation and direct authentication with Azure AD. Though direct authentication is technically the simplest method of the two, it requires enabling a feature known as password sync. And I think password sync is a pretty poorly understood feature that deserves more explanation.
Microsoft offers two ways to handle authentication to Azure AD: identity federation, or direct authentication using Azure AD itself. Identity federation with a federation service such as AD FS or PingFederate provides single sign on to Azure AD by redirecting users from the cloud service back to their local AD for authentication. The other option, direct authentication in Azure AD, requires that the user’s userid and password be stored locally in the cloud service. For enterprises, this must be done with the password sync feature of Microsoft’s AD Connect service; no third party provides an equivalent capability.
What is password hash sync and why use it?
At its simplest, cocktail-party-napkin-sketch level, password hash sync (a more accurate description, which I’ll explain below) copies the user’s password from AD to Azure AD every two minutes. This allows users to login to Azure AD with the same userid and password they use for their AD login. Microsoft calls this pattern same sign on. It’s distinct from single sign on because with password hash sync, users will be prompted to login to Azure AD in addition to any corporate login they’ve done.
Why would you want to use password hash sync? Mostly because it’s simpler to implement than a federation service. Microsoft needed to provide an easy way to integrate on-premises AD users with Azure AD, and Password hash sync does this without the need for a multiple server, highly available federation service.
And the simpler solution has provided to be popular; about 50% of organizations that synchronize with Azure AD use password hash sync. Of that 50%, half are small and medium sized organizations. Password hash sync provides a smooth path for these organizations to move to a cloud-first or cloud-only IT infrastructure, because users are already authenticating directly with the Azure AD service.
Another advantage of password hash sync is that, unlike federation, it doesn’t depend upon an external federation service to process authentications. In fact, Microsoft offers password hash sync in addition to federation so it can be used as a fallback if your federation service has an outage.
How secure is password hash sync?
Note that I describe this feature as password hash sync – not password sync. It’s an important distinction. Cleartext passwords are not synchronized between AD DS and Azure AD. Not only is it not a good idea, it’s not even technically possible because Active Directory doesn’t have the cleartext passwords. When a user creates or updates their password in AD, it is stored as a one-way MD5 hash on the domain’s DCs. This hash is what’s synchronized to Azure AD and stored in the service’s credentials store.
How does it work, exactly? I’ve compiled the following steps from Alex Simon’s blog post AAD Password Sync, Encryption, and FIPS Compliance and a few other sources:
- User passwords are stored as a non-reversible hash in Windows Server Active Directory Domain Controllers (DCs). When the password sync agent on AD Connect attempts to synchronize the password hash, the DC encrypts the hash. The encryption is performed with a key derived from the RPC session key by salting it. The key derivation is as follows [where SaltedEncryptionKey = MD5 (RPC session Key, 128 bit random salt)]. The DC also passes the salt to the sync agent using the replication protocol.
- The original password hash is replicated (using the DC replication protocol) from the DC to the Password Sync Agent.
- The Password Sync Agent decrypts the encrypted hash by deriving the key as described above. The password sync agent uses MD5 to perform the key derivation, as the derivation has to be identical to the derivation the DC performed (when it encrypted the data). And MD5 is the highest level available for this action in the DC replication protocol of existing Windows Server Active directory deployments.
- Once the decryption is done, the sync agent takes the resulting original password hash and re-hashes it to a SHA256 hash by using PKDF2 key derivation algorithm as defined in RFC 2898.
- The Password Sync Agent then syncs that SHA256 hashed password hash over the wire (an encrypted Service Bus relay dedicated to the Azure AD tenant) to Azure AD.
- Once the SHA256 hashed copy of the original password hash reaches Azure AD, Azure AD encrypts the hash with the AES algorithm before storing it in the cloud database.
The only thing that crosses the wire on the way to Azure AD is a SHA256 hashed copy of the original password hash. The password sync agent’s use of MD5 is strictly for replication protocol compatibility with the DC, and is only used, on premises, between the DC and the password sync agent.
Password hash sync disadvantages
From a user’s view point, the most obvious disadvantage is that the user must enter their corporate credentials a second time regardless of whether they’re logged in to their corporate network, or outside on a public network. These logins can be reduced, however, by checking the “Keep me signed in” (KMSI) checkbox. Checking this sets a session cookie that bypasses authentication for a short period. Your security team will want to weigh in on this, and the KMSI behavior can be enabled or disabled by the Azure AD administrator.
From the identity professional’s view point, the problem with password hash sync is that you’re distributing password to more than one place for authentication. In contrast, federation redirects all authentication requests back to the identity provider. Microsoft has gone to great lengths to ensure the process is safe, but it’s valid to ask questions about the password’s lifecycle.
When must you use Password hash sync?
There is one use case when you must use password hash sync: if you choose to implement Azure AD Domain Services. This feature creates a domain controller as a service that Azure applications (such as VMs running AD-dependent applications) can use. For these DCs to be functionally equivalent to on-premises DCs, however, they must have user password hashes, and thus require password hash sync to get them into Azure.
Password hash sync is a popular solution for integrating your on-premises identities with Azure AD. It’s not as elegant as using identity federation, but it’s simpler. As with any design decision, be sure you’ve though through this solution’s strengths and weaknesses and how they apply to your situation.
