Selective password synchronization with AAD-Connect

In my previous post, I talked about the possibility of using Kerberos Constraint Delegation to avoid having passwords in AAD. However, sometime you want to have a few passwords in AAD-Domain Services to ensure that administrators can still login to the VM’s interactively (RDP) or users are able to use certain services that are not published with Kerberos or aren’t web services.

In this post we will look at editing the configuration of AAD-Connect to synchronize the passwords* of users that have an attribute in AD present so that some users (like administrators) will be able to login to VM’s joined to AAD-DS using their on-premises passwords.

* see note below

In my configuration, I used the attribute called employeeType in Active Directory. If you want, you can use any attribute you want (such as extensionAttributeX or the latest custom attributes in AD for cloud called msDS-cloudExtensionAttributeX).

I began with installing AAD-Connect in a custom installation and followed the standard installation; I specified Federated Logins (or if you already have this all configured, choose do not configure now). On the options page I selected to synchronize passwords, but I disabled the initial sync or staging.

Now, we have to go into the ruleset. For this we need to start: “C:\Program Files\Microsoft Azure AD Sync\UIShell\SyncRulesEditor.exe”

In the editor we see a number of rules in the order:

In from AD – User Join (precedence 100)
In from AD – InetOrgPerson Join (101)
In from AD – User AccountEnabled (102)

The precedence number is the order in which the rules are executed. Since we want to add some rules, we need to make some room in the order. To do this, click on In from AD – User Join – 100) and click edit. In the pop-up, select NO.

The message comes up, as the default rules are built-in rules for which changing the configuration is not advised. However in our case, we don’t change any of the properties of the rule itself, but only the order. Since only the order of the rules matter and not the actual precedence number, I made a lot of room for my other rules by providing the number 90 as the start number.

Do the same for the next rule – In from AD – InetOrgPerson Join and give it the precedence 95.

Now that we have some room, we go to the actual configuration.

Select the In from AD – User AccountEnabled (102) and on the pop-up, click YES to create a copy of the rule. In the rule name set it to “In from AD – User AccountEnabled – WithPassword”. When the copy is open, set the precedence to 101 and ensure that the EnablePasswordSync option is selected.

Click on next to go to the scoping filter. This is the actual filter we will setup to ensure only objects that we want to have the password synchronized are using this rule.

In the scoping filter window, select Add Clause and then on the attribute select your attribute you selected. In my case I choose employeeType and I set the Operator to ISNOTNULL.

This means that in my case, IF the employeeType attribute of a user has at least something in it, the password will be synchronized. You can also make it more specific, stating EQUAL or CONTAIN “SyncPass” and then the attribute must have “SyncPass” set to it in order for user passwords to be synchronized rather than just any type of text.

Save the rule. If you get a pop-up on missing attributes in the schema, click YES to continue the saving of the configuration.

Next we are going to create the rule that does not synchronize the passwords (but does synchronize the users) if the attribute (in my case employeeType) is not set at all. Which by default means all users.

In order to do this, we go back to our original rule, click edit and in the pop-up select YES again to create a copy.

This copy will be named: “In from AD – User AccountEnabled – noPassword”. Give the rule a precedence of 100 so that it goes on top of the “withPassword” rule. On the main page, ensure that Enable Password Sync is not selected, and that the rule is not disabled.

On the Scoping filter tab, ensure that you add a new clause, that states, Attribute ISNULL. Where attribute is set to your attribute (in my case employeeType).

Here you see the filter that is actually being used to sync users without their passwords, as you can imagine if you have the filter for rule 101 set to a specific word, it means users can fall out of the replication all together. If you do use the EQUAL or CONTAINS operators, some users that have a wrong entry in the attribute will not be synced at all. This is something to keep in mind when troubleshooting.

Save the rule.

The last thing we need to do is ensure that the attribute type that we chose for the filter is imported during the import operation of the AD connector. For this we need to open the miisclient. “C:\Program Files\Microsoft Azure AD Sync\UIShell\miisclient.exe”

Go to the connectors page and select the Active Directory Domain Services connector. Click Properties to open the configuration and select the Select Attributes on the left side of the window. Ensure that there is a checkbox next to your attribute. If it is not shown, ensure that you click the show all checkbox on the top.

Validating the configuration

So how do we know this all worked.. and which users use which rules? Firstly, lets ensure we have two users in AD. One with the attribute set, and others without. Then in the MIIS client select the AD connector and select RUN – full import. It will import all the users in the connector space. In the statistics you will see the add’s (blue underlined). Open that one and you will see the actual user objects being imported. When you open the user being imported, you will see the connector space properties:

Click the preview button, and on the Preview window, click Generate Preview, while the preview mode is set to Full synchronization.

As you can see in the image below, the actual rule being used is the withPass ruleset. Which means the password IS being replicated to AAD.

So what does this all mean now. Users will still be using federated logins to login to for example their Office 365 account (if the domain is set to federated). But it does mean that the user password is ALSO available on AAD to be replicated into AAD-DS. And that is where the value lies. If a user password is available in AAD-DS it means this user is able to login to VM’s or services bound to the AAD-DS domain, while all other users without passwords are not able to regardless of any policy or group membership. Given the password is not there for some users, they will never be able to login interactively. Only through Kerberos Constraint Delegation.

Starting Sync

Lastly what needs to be done is to enable the sync, restart the configuration (Azure AD Connect from the desktop), click customize synchronization options and click next.. provide an administrator account for AAD and click next, next next.. not changing anything on the configuration.. on the last page, select Start the synchronization process…. and click Finish.

Note on Password synchronization: The synchronization of passwords into the cloud towards Azure AD uses multiple techniques to ensure the safety and confidentiality of the data. Instead of uploading the actual passwords, a hash will be uploaded into Azure AD (passwords are never reversible encrypted – A Secure PBKDF2 key derived from the SHA256 hash of the MD4 has of the password is sent https://azure.microsoft.com/en-us/documentation/articles/active-directory-aadconnect/)
This means that for the on-premises Active Directory, passwords do not have to be stored with reversible encryption, and it means that for the replication passwords are never stored/transported in clear text, or encrypted clear text. Even the passwords in the AAD-DS for users are stored in the double-hashed format.