AD to AAD object matching

  • Last Post 3 days ago
kool posted this 3 weeks ago

Hi gang, Happy Holidays and Happy New Years!

We have the AAD Connect EnableSoftMatchOnUpn set to True. We'd like to be able to pre-stage new users in AAD so that a license can be applied and a mailbox created before the on-prem AD object is created. Both objects would obviously have the same userPrincipalName. In my testing I'm seeing AADC creating a new object rather than matching on UPN. There are no proxyAddress values on the pre-staged user object at this point, but rather than update the immutableId to match the base64-encoded on-premise objectGUID it creates a different object. Now this does seem like an oxymoron, you wouldn't expect the immutableId to be changeable except what's the point of matching on other attributes if immutableId overrides everything else? discusses the soft match feature.

Note that we have not changed the source anchor ( We are somewhat leery of making a change like this that impacts several hundred thousand active users in our directory. We don't fully understand the ramifications and side-effects of making this change. It would however give us a way to supply the matching value to ensure the proper connection.

I've devised a work-around that is less impactful than changing the source anchor. I can pre-create the user object in AD in an OU that doesn't sync. I grab the objectGUID, base-64 encode it and supply that as the immutableId when creating the pre-staged AAD object. At a later point when I move the AD object to a syncing OU they do indeed match properly.

Clearly I'm missing some bit about how soft matching is supposed to work as it doesn't work at all in my experimenting. Does anyone have any deeper insights into my conundrum?


    Eric Kool-Brown
    Software Engineer
    University of Washington - IT Infrastructure

Forum info:
Problems unsubscribing? Email admin@xxxxxxxxxxxxxxxx

Parzival posted this 3 days ago


If you have pre-created used in the Azure AD using a syncEngine, the UPN Softmatch does not work. You would have to force the object ImmutableID to update (matching the on-premises user cloudSourceAnchor) prior to configuring the Sync (or move the user in the

correct OU). Reason is that an immutableID is already created for the object and that is not updated automatically. Your workaround is indeed correct, you create an object on-premises, retrieve the Base64(ObjectGuid) and set that as the immutableID upon creation

of the object. Then when the sync run's it finds eachother and all is well. (

With regards to the ConsistencyGuid. If you are using a later version of AzureADConnect it is already using the ConsistencyGuid (unless you did in-place upgrades). For this, it copies the ObjectGUI into the ConsistencyGuid and then uses that as the source

anchor (base64 encoding) - as you indicated. The consistencyGuid allows you to have an influence over the ImmutableID in case of AD-AD migrations.  See also my latest blog entries in about the consistencyGuid rules.

Using the MIIS client you can actually predict what will happen and if the objects are being matched correctly (and on which attributes). You can take a look at my presentation from the Hybrid Identity Conference in NY "back in '17" (sorry for the coughing - the weather was ehm different than what I'm used to). Look at the Azure AD Connect the world is not enough 2 presentation, where I did a demo of using MIIS, going through the rulesets in AADConnect and using the extensionAttribute1

for a link between old and new AD forests.. its more to show you where to look is MIIS, how the matching is done and how you can preview it all etc..