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.
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.
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.
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.
Under Scoping filter let’s add another filter that we can use our extension attribute as a criterion.
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.
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.
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
The process can now be done well Synchronization Service Manager to be watched.
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.
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:
The complete troubleshooting description from Microsoft is can be found here.