Implement password hash synchronization with Azure AD Connect - Microsoft Entra synchronization (2023)

This article provides information you need to synchronize user passwords from an on-premises Active Directory instance to a cloud-based Azure Active Directory (Azure AD) instance.

How password hash sync works

Active Directory Domain Services stores passwords as a hash value representation of the actual user password. A hash value is the result of a one-way mathematical function (thehashing algorithm). There is no method to return the result of a one-way operation to the plaintext version of a password.

To synchronize your password, Azure AD Connect synchronization extracts your password hash from your internal Active Directory instance. Additional security processing is applied to the password hash before it is synchronized with the Azure Active Directory authentication service. Passwords are synchronized per user and in chronological order.

The actual data flow of the password hash synchronization process is similar to user data synchronization. However, passwords are synced more frequently than the standard directory sync window for other features. The password hash synchronization process is performed every 2 minutes. You cannot modify the frequency of this process. When you sync a password, it replaces your existing cloud password.

The first time you enable the password hash synchronization feature, it performs an initial synchronization of the passwords of all users in a domain.Gradual dispositionallows you to selectively test groups of users with cloud authentication features such as Azure AD Multi-Factor Authentication (MFA), Conditional Access, Identity Protection for leaked credentials, Identity Governance, and more, before cutting off your domains. You cannot explicitly define a subset of user passwords that you want to synchronize. However, if there are multiple login sockets, it is possible to disable password hash synchronization for some sockets but not others usingSet-ADSyncAADPpasswordSyncConfigurationcmdlet.

When you change an on-premises password, the updated password syncs, usually within minutes. The password hash sync feature automatically retries failed sync attempts. If an error occurs during an attempt to synchronize a password, an error is logged in the event viewer.

Synchronizing a password has no effect on the currently logged-in user. Your current cloud service session is not directly affected by a synchronized password change that occurs while you are logged in to a cloud service. However, when the cloud service requires re-authentication, you must provide your new password.

A user must enter their corporate credentials a second time to authenticate to Azure AD, regardless of whether they are connected to their corporate network. This pattern can be minimized, however, if the user selects the Keep me logged in (KMSI) check box when logging in. This option sets a session cookie that bypasses authentication for 180 days. KMSI behavior can be enabled or disabled by your Azure AD administrator. Additionally, you can reduce password prompts by configuring the settingsAzure AD integrationtheHybrid Azure AD connection, which automatically connects users when they are on their corporate devices connected to your corporate network.

Additional benefits

• In general, password hash synchronization is simpler to implement than a federation service. It requires no additional servers and eliminates reliance on a highly available federation service to authenticate users.
• Password hash synchronization can also be enabled in addition to merging. It can be used as a fallback if your federation service experiences an outage.

Detailed description of how password hash synchronization works

The following section describes, in depth, how password hash synchronization works between Active Directory and Azure AD.

1. Every two minutes, the password hash synchronization agent on the AD Connect server requests stored password hashes (the unicodePwd attribute) from a DC. This request is made through the templateMS-DRSRreplication protocol used to synchronize data between DCs. The service account must have Replicate Directory Changes and Replicate Directory Changes All AD rights (granted by default during installation) to obtain password hashes.
2. Before sending, the DC encrypts the MD4 hash of the password using a key that is aMD5hash of the RPC session key and a salt. It then sends the result to the password hash synchronization agent via RPC. The DC also passes the salt to the synchronization agent using the DC replication protocol so that the agent can decrypt the folder.
3. After the password hash sync agent has the encrypted folder, it usesMD5CryptoServiceProviderand the salt to generate a key to decrypt the received data back to its original MD4 form. The password hash synchronization agent never has access to the clear text password. The use of MD5 by the password hash synchronization agent is strictly for replication protocol compatibility with the DC and is only used on premises between the DC and the password hash synchronization agent.
4. The password hash sync factor expands the 16-byte binary password hash to 64 bytes by first converting the hash to a 32-byte hexadecimal string and then converting that string back to UTF-16-encoded binary.
5. The password hash synchronization factor adds a per-user salt, consisting of a 10-byte long salt, to the 64-byte binary to further protect the original hash.
6. The password hash synchronization agent then combines the MD4 hash plus the per-user salt and inserts it intoPBKDF2mode. 1000 repetitions of itHMAC-SHA256A keyed hashing algorithm is used. For more details, seeAzure AD White Paper.
7. The password hash sync agent takes the resulting 32-byte hash, concatenates both the per-user salt and the number of SHA256 repetitions into it (for use by Azure AD), and then broadcasts the string from Azure AD Connect to Azure AD over TLS.
8. When a user attempts to sign in to Azure AD and enters their password, the password is run through the same MD4+salt+PBKDF2+HMAC-SHA256 process. If the resulting hash matches the hash stored in Azure AD, the user has entered the correct password and has been authenticated.

Security Issues

When synchronizing passwords, the plaintext version of your password is not exposed to the password hash synchronization feature, Azure AD, or any of the related services.

User authentication is against Azure AD, not against the organization's own Active Directory instance. SHA256 password data stored in Azure AD—a hash of the original MD4 hash—is more secure than that stored in Active Directory. Additionally, because this SHA256 hash cannot be decrypted, it cannot be brought back into the organization's Active Directory environment and presented as a valid user password in a pass-the-hash attack.

Password Policy Issues

There are two types of password policies that are affected by enabling password hash synchronization:

• Password complexity policy
• Password Expiration Policy

Password complexity policy

When password hash synchronization is enabled, password complexity policies in the on-premises Active Directory instance override complexity policies in the cloud for synchronized users. You can use all valid passwords from your on-premises Active Directory instance to access Azure AD services.

Password Expiration Policy

If a user is in the scope of password hash synchronization, by default the cloud account password is set toMay it never expire.

You can continue to sign in to your cloud services using a synced password that has expired in your on-premises environment. The cloud password is updated the next time you change the password in the on-premise environment.

EnforceCloudPasswordPolicyForPasswordSyncedUsers

If there are synchronized users that only interact with Azure AD built-in services and also need to comply with a password expiration policy, you can force them to comply with the Azure AD password expiration policy by enablingEnforceCloudPasswordPolicyForPasswordSyncedUsersfeature.

whenEnforceCloudPasswordPolicyForPasswordSyncedUsersis disabled (which is the default setting), Azure AD Connect sets the PasswordPolicies attribute of synchronized users to "DisablePasswordExpiration". This is done every time a user's password is synced and instructs Azure AD to ignore the cloud password expiration policy for that user. You can check the value of the attribute using the Azure ADPowerShell module with the following command:

(Get-AzureADUser -objectID).passwordpolicies

To enable the EnforceCloudPasswordPolicyForPasswordSyncedUsers feature, run the following command using the MSOnline PowerShell module as shown below. You should type yes for the Enable parameter as shown below:

Set-msoldirsyncfeature -feature enforcecloudpasswordpolicyforpasswordsynceduserscmdlet set-msoldirsyncfeature at Pipeline Poseline places 1S-supply values ​​for the following parameters: enable: yesconfirmcontinue with this feature? : y

Once enabled, Azure AD does not go to every sync user to remove itDisablePasswordExpirationvalue from the PasswordPolicies attribute. On the contrary, theDisablePasswordExpirationThe value is removed from Password Policies during the next password hash sync for each user, at the next internal AD password change.

After theEnforceCloudPasswordPolicyForPasswordSyncedUsersThe feature is enabled, new users are provisioned without a PasswordPolicies value.

The default Azure AD password policy requires users to change their passwords every 90 days. If your AD policy is also 90 days, the two policies should match. However, if the AD policy is not 90 days, you can update the Azure AD password policy to match using the Set-MsolPasswordPolicyPowerShell command.

Azure AD supports a separate password expiration policy per registered domain.

Warning: If there are synchronized accounts that must have passwords that do not expire in Azure AD, you must explicitly add theDisablePasswordExpirationvalue in the PasswordPolicies attribute of the user object in Azure AD. You can do this by running the following command.

Set-AzureADUser -ObjectID-PasswordPolicies "DisablePasswordExpiration"

Sync temporary passwords and "Force password change on next login"

It is typical to force a user to change their password on their first login, especially after resetting the admin password. It is commonly known as setting a "temporary" password and is accomplished by checking the "User must change password at next logon" flag on a user object in Active Directory (AD).

The temporary password feature helps ensure that the transfer of credential ownership is completed on first use, to minimize the amount of time more than one person knows these credentials.

To support temporary passwords in Azure AD for synchronized users, you can enable itForcePasswordChangeOnLogOnfeature by running the following command on the Azure AD Connect server:

Set-ADSyncAADCompanyFeature -ForcePasswordChangeOnLogOn $true

Account expiration

If your organization uses the accountExpires attribute as part of user account management, this attribute is not synchronized with Azure AD. As a result, an expired Active Directory account in an environment configured for password hash synchronization will still be active in Azure AD. We recommend using a scheduled PowerShell script that disables users' AD accounts after they expire (use theSet-brought itcmdlets). Instead, during the process of unexpiring an AD account, the account must be reactivated.

Replace synchronized passwords

An administrator can manually reset your password directly in Azure AD using Windows PowerShell (unless the user is in a Federated Domain).

In this case, the new password overrides your synced password and all password policies set in the cloud are applied to the new password.

If you change your on-premises password again, the new password is synced to the cloud and overrides the manually updated password.

Synchronizing a password has no effect on the signed-in Azure user. Your current cloud service session is not directly affected by a synchronized password change that occurs while you are connected to a cloud service. KMSI extends the duration of this dispute. When the cloud service requires re-authentication, you must provide your new password.

Password hash synchronization process for Azure AD domain services

If you use Azure AD Domain Services to provide legacy authentication for applications and services that must use Kerberos, LDAP, or NTLM, some additional processes are part of the password hash synchronization flow. Azure AD Connect uses the following additional process to synchronize password hashes in Azure AD for use in Azure AD Domain Services:

1. Azure AD Connect retrieves the public key for the Azure AD Domain Services tenant instance.
2. When a user changes their password, the on-premises domain controller stores the result of the password change (hashes) in two attributes:
   • unicodePwdfor NTLM password hashing.
   • additional credentialsfor Kerberos password hashing.
3. Azure AD Connect detects password changes through the directory replication channel (attribute changes that need to be replicated to other domain controllers).
4. For each user whose password has changed, Azure AD Connect performs the following steps:
   • Generates a random 256-bit AES symmetric key.
   • Generates a random initialization vector needed for the first round of encryption.
   • Extracts Kerberos password hashes fromadditional credentialsattributes.
   • Checks the security configuration of Azure AD domain servicesSyncNtlmPasswordscomposition.
     • If this setting is disabled, a random high-entropy NTLM hash (different from the user's password) is generated. This hash is then combined with the exact Kerberos password hashes from theadditional Rightsattribute in a data structure.
     • If enabled, combines its valueunicodePwdattribute with the Kerberos password hashes extracted from theadditional credentialsattribute in a data structure.
   • Encrypts the individual data structure using the AES symmetric key.
   • Encrypts the AES symmetric key using the tenant's Azure AD Domain Services public key.
5. Azure AD Connect transmits the encrypted AES symmetric key, the encrypted data structure containing the password hashes, and the initialization vector to Azure AD.
6. Azure AD stores the encrypted AES symmetric key, encrypted data structure, and initialization vector for the user.
7. Azure AD pushes the encrypted AES symmetric key, encrypted data structure, and initialization vector using an internal synchronization mechanism over an encrypted HTTP session to Azure AD Domain Services.
8. Azure AD Domain Services retrieves the private key for the tenant instance from the Azure Key vault.
9. For each encrypted data set (representing a single user's password change), Azure AD Domain Services then performs the following steps:
   • It uses its private key to decrypt the AES symmetric key.
   • It uses the AES symmetric key with the initialization vector to decrypt the encrypted data structure containing the password hashes.
   • Registers the Kerberos password hashes it receives to the Azure AD Domain Services domain controller. Hashes are stored in the user objectadditional credentialsattribute that is encrypted in the public key of the Azure AD Domain Services domain controller.
   • Azure AD Domain Services writes the received NTLM password hash to the Azure AD Domain Services domain controller. The hash is stored in the user objectunicodePwdattribute that is encrypted in the public key of the Azure AD Domain Services domain controller.

Enable password hash synchronization

When you install Azure AD Connect using theExpress settingsoption, password hash synchronization is automatically enabled. For more information, seeGetting started with Azure AD Connect using express settings.

If you use custom settings when installing Azure AD Connect, password hash synchronization is available on the user login page. For more information, seeCustom installation of Azure AD Connect.

Synchronize password hashing and FIPS

If your server is locked down according to the Federal Information Processing Standard (FIPS), then MD5 is disabled.

To enable MD5 for password hash synchronization, perform the following steps:

1. Navigate to %programfiles%\Microsoft Azure AD Sync\Bin.
2. Open miiserver.exe.config.
3. Go to the configuration/runtime node at the end of the file.
4. Add the following node:
5. Save your changes.
6. Reboot for the changes to take effect.

For reference, this snippet is what it should look like:

For information about security and FIPS, seeAzure AD password hash synchronization, encryption and FIPS compliance.

Troubleshoot password hash sync issues

If you're having trouble syncing password hashes, seeTroubleshoot password hash sync issues.

Next steps

• Azure AD Connect sync: Customize sync options
• Integrate your internal identities with Azure Active Directory
• Resources for migrating applications to Azure AD