Sync password hashes with Azure Active Directory Connect

If companies do not want to transfer the password hashes to the cloud in a hybrid configuration consisting of a local AD and Azure AD, they can interpose ADFS for authentication. A compromise would be to only match the passwords of certain users with AAD Connect.

One use case for a mixed Active Directory is a hybrid installation of Exchange. It requires the synchronization of accounts between on-prem and the cloud. For authentication, Microsoft offers the Password hash synchronization an option that can replace the installation of complex ADFS in many cases.

Hash synchronization depending on the AD attribute

This post is about synchronizing the password hash of certain users or user groups with the Microsoft 365 cloud. We use attribute filtering. In our example, we synchronize all users who have the value AAD in the extensionAttribut3 have included.

We are going to do two custom rules in the Synchronization Rules Editor create. The first replicates users with and the second without a password hash. We also disable the default password hash rule because we no longer need it.

Before we configure the new rules, we switch off the password hash synchronization in the AAD Connector.

Before defining rules for the synchronization of password hashes, you should deactivate the latter.

Copy of the standard rule as the basis for a new rule

In the sync rule editor, we are now looking for the default password sync rule.

Open the standard rule for password synchronization in the Rules Editor

We create a copy of this rule by marking it up and on Edit click. We are then offered to make a copy of this rule.

Make a copy of the default rule for synchronizing password hashes

Rule for synchronizing without hashes

First we create the rule without the password hash. A corresponding name should reflect its purpose so that it can be found more easily later for changes. You also have to change the priority, for example to a value of 90. This is necessary because the rules we have created are to be executed before the standard rules, which start at priority 100.

The check boxes Enable Password Sync and Disabled are not checked and therefore remain empty.

Create rule for those accounts whose password hash should not be synchronized to the cloud.

Under Scoping filter let’s add another filter that we can use our extension attribute as a criterion.

The filter should check whether the string 'AAD' is not contained in the extensionAttribute3.

We do not have to adapt more to this rule. The editor can now use the button to save getting closed.

Rule for synchronizing the hashes

Following the same pattern, we now create the rule that we need to synchronize the password hashes, but with some changes.

The priority is now 89 because this rule should run before the rule just created. We also check the box Enable Password Sync this time.

Create rule for those accounts whose password hash should be synchronized to the cloud.

In the Scoping filter area, the NOTEQUAL becomes an EQUAL, since the condition should now apply if the value AAD is included in the attribute.

All accounts whose extensionAttribute3 contains the value 'AAD' are selected via the filter

This rule can now also be closed with Save. A small window always comes up with a note, which is confirmed with Ok.

Then you should start a complete synchronization with PowerShell using the following command:

Start-ADSyncSyncCycle -PolicyType Initial

Initiate initial synchronization using the Start-ADSyncSyncCycle cmdlet

The process can now be done well Synchronization Service Manager to be watched.

Monitor synchronization of password hashes in the Synchronization Service Manager

Finally, we reactivate the password hash synchronization via the AAD connector.

If a user changes their password in the local domain, it can take up to five minutes to be up to date in Microsoft 365.

The event display on the AAD Connect server in the area helps for troubleshooting application further. There you should take a closer look at the events with the ID 656 and 657.

For troubleshooting you should look for entries with ID 656 and 657 in the event log.

To check password synchronization using PowerShell, you can use the Invoke-ADSyncDiagnostics cmdlet, which is included in AAD Connect from version 1.1.524.0:

Invoke-ADSyncDiagnostics -PasswordSync

The Invoke-ADSyncDiagnostics cmdlet is another tool for tracking down errors in synchronization.

The complete troubleshooting description from Microsoft is can be found here.

You May Also Like

About the Author: Jan Gruber

Leave a Reply

Your email address will not be published. Required fields are marked *