Using AADConnect to merge users originating in AzureAD

I shortly came into a situation with a customer who’s got to have OnPremise IT infrastructure for the first time. As a start-up they began with BYOD and some SaaS applications incl. a Hosted Exchange.

Since they are and will be heavily growing over the next few years they decided to plan and implement an IT infrastructure OnPremise with only a few components for security and client deployment including an Active Directory and combine that with Office365 and AzureAD for Mail and SaaS Application Management.

The migration from Hosted Exchange to O365 is already done, which leads into user account in Azure AD for all 250 users. I’ve implemented the Active Directory for them and now want to synchronize OnPrem AD Users with AzureAD.

But since all account are in Azure AD, I have to do an initial import of those accounts from Azure AD to OnPrem. And that’s where the issues began.

In addition all users currently have a valid password set in Azure AD and already using them productive it is not that easy to avoid overriding those password if I active password hash sync, which is what the customer wants.

First my thought was to use user write back (a new feature in AADConnect) but that leads into 2 issues:

1. Currently Password Sync/Write back is broken on accounts using user write back, even in RTM of AADConnect, which is ok as user write back is still a preview feature where bugs can happen.
2. If I turn off user write back after an initial sync to OnPrem AD the accounts will be deleted from AD, that’s bad 😦

Ok then, another strategy:

I extracted the user account from AzureAD via PowerShell and import them into OnPrem AD. When doing Full Import (Stage Only) on the AAD Connector I could see that the cloud mastered accounts where not staged into the connector space. Seems there is some kind of default filter on this connector which you cannot see or modify.

Some testing leads to the fact that this filter is based on the sourceAnchor (immutableID) of the AzureAD account. In addition when looking to the sync rules you will see that the join criteria of user accounts is the sourceAnchor (immutableID).

So AADConnect can easily join (merge) AAD and OnPrem Accounts if they were synchronized sometime in the past, but you cannot join/merge new existing accounts!

Since I know how to create the sourceAnchor (immutableID) from previous projects I’ve done the following:

• Export users from AAD and import them to AD via PowerShell (don’t miss additional attributes)
• Create the sourceAnchor (immutableID) by getting the objectGUID of the OnPrem AD account, do a Base64 encode of it and put that value on the immuableID attribute of the Azure AD account

Here is a little script on how to do that from my early testing’s of a single object.

Import-Module ActiveDirectory
Import-Module MSOnline

$cred = Get-Credential
Connect-MsolService -Credential $cred

$GUIDbyte = (Get-ADUser peter).objectGUID.ToByteArray()
$immuID = [System.Convert]::ToBase64String($GUIDbyte)

Set-MsolUser -UserPrincipalName peter@mydomain.de -ImmutableId $immuID

After that I’ve start the following full sync cycle manually in AADConnect:

• AD: Full Import
• AAD: Full Import
• AD: Full Sync
• AAD: Full Sync
• AAD: Export (which will modify some attributes which should be already in AzureAD)

And finally I’ve got my OnPrem and Azure AD account synchronized.

Another point was the Password Sync / Write back issue, since currently all valid and in use password where in Azure AD I don’t want to get them overwritten by the “default” password I’ve set on the OnPrem AD accounts, so what to do.

Activating and password write back relies on activating password hash sync, which will do an initial sync of all OnPrem account password to the cloud first, with one exception:

Password Sync will not be done if you set the flag “user must change password on next logon” on the OnPrem AD accounts, so that saved my day but leads to a “not so nice” behavior on password changes in the cloud this first time users need to do that.

But now a user can change his password in Azure AD and with activated password write back the password flows back to OnPrem AD and will also clear the “user must change pw on next logon” flag.

The only special behavior on this first password change of users in Azure AD is that the user doesn’t have to user his “real” current password to set a new password, instead he has to use the “default” password which I set on creation of the OnPrem accounts.

The reason of that is simple if you know how password write back works:

Password write back captures the current and new password the users entered and sends it through a secure tunnel (which the PW Sync feature started from OnPrem to Azure) as cleartext.

The DC then checks if the current PW is correct (which in the current state because of a missing initial pw sync is the OnPrem PW). Also the new password is checked against the password policies which only can be done if the password it known in cleartext.

But in the situation at my customer this same default PW for all users is no problem, since none of the users are currently domain joined (this will be done in the next weeks). If you want that behavior to be more secure you can create a “good” password for every user when creating the OnPrem AD account.

The above sounds a little complicated but this had some advantages for the customers and his users:

• New OnPrem and AzureAD accounts never synced before got merged.
• Initial PW Sync was skipped so the AzureAD PW remains “valid”.
• User has to change his PW only one time, and this can be now, in 30 days or later.

The disadvantage is that the user has to use the OnPrem “default” password which has be set by the administrator (me) and not what the change dialog said his “current password”. But since the user must first authenticate with his current Azure credentials and after that change his password this scenario should be safe enough.

Advertisement