Whether you love it or hate it, AD Connect is still vital to many organizations. As more organizations shift away from Hybrid joined devices, some applications or business processes still rely on AD Windows Authentication for applications or Kerberos for legacy services, like SMB file shares. For that, AD connect is still required for SSO to legacy applications (not for the devices, but for the user identities). It’s important to understand that devices can be AADJ and still seamlessly access on-prem legacy workloads as long as the user identity is synced via AD connect. For details on that, see this post. That’s not what this post is about, though. This post is about how to manually hard match on-prem and cloud user identities when you’re having difficulty getting an on-prem identity to sync with the correct cloud identity. Let’s do a quick review of how AD Connect matches user identities.
Azure AD Connect is a rather simple tool. There is more happening on the back end, but we rarely need to manually intervene once it’s up and running. At a high level, here’s what happens when matching & syncing User Identities:
- User accounts from selected OU’s in AD are compared against Azure AD identities. The first thing AD Connect looks for is a source anchor. By default, this is the mS-DS-ConsistencyGUID attribute in AD. In Azure AD, this is referred to as the immutable ID. “Source Anchor” and “Immutable ID” are basically interchangeable terms and refer to those values. If an account has a source anchor value, it means it’s either already matched, or it was previously matched at some point. If an AAD and AD identity have the same source anchor, this is considered a hard match.
- If there is no immutable ID value set, then Azure AD tries to do a “soft match” on the UPN or Primary SMTP address. This usually works well if your AD UPN and Primary SMTP address match Azure AD. You can run the IDFix tool from Microsoft to identify any problematic values beforehand. If a soft match is made, then Azure AD generates an immutable ID and stamps it on the Azure AD identity, on the next sync cycle, that immutable ID value is written to the AD identity as the mS-DS-ConsistencyGuid attribute value, and the two accounts are now linked by the source anchor as a hard march. If this is a new user account in AD, then a new identity is created in Azure AD to match the UPN and other necessary attributes from AD, and the same process happens with the immutable ID assignment.
The key thing to take away from this is the Source Anchor. Once that is set on both identities, they’re married with a hard match. It’s also important to remember that when using AD Connect, Active Directory is the source of authority for the identities and all attributes are managed in AD. You have very little ability to edit user accounts in Azure AD if the identity is synced. Nearly all user account changes need to happen in AD, which gets synced to Azure AD via AAD Connect. Most AD Connect issues are easy to resolve by evaluating the error message, and then making corrections. However, there are two situations where you’ll likely need to manually intervene and assign a source anchor value to one of the identities, which will result in a manual hard match. This usually happens when a previously synced cloud identity can’t be matched to an on-prem account, or when a cloud-managed identity cannot be matched to an on-prem account due to a duplicate value error.
Situation 1 – Previously synced cloud identity can’t match to new AD identity
The most likely situation where this happens is a synced account is deleted permanently from AD (whether it’s intentional or not). When this happens, the cloud identity is deleted on the next sync cycle. If that account is restored in Azure AD, it will be converted to a cloud-managed identity. All good, right? Well, since that now cloud-managed identity already has a source anchor value, it won’t be matched to a newly created AD account, since the newly created AD account will not have a source anchor. You need these accounts to match, but how can we do this? For one-off situations like this, the best solution is to statically set the source anchor value of the Azure AD identity to the AD identity. If those two values match, you end up getting a hard match and all is good. We can reproduce this and walk through it all pretty easily:
We can see my user account here, Bret Hart, which is currently being synced:
If I delete him permanently from AD and run a sync, he will be deleted from AAD since AD connect doesn’t see him anymore:
When this happens in a production environment, maybe Bret Hart returned to the company a week or two later. Or he was mistakenly deleted. Regardless of the reason. the administrator realizes the cloud account is gone, and they restore it from Azure AD.
OK… He has been restored. But since he was restored, the account is now cloud managed:
That’s OK let’s just make a new Bret Hart in AD and AD connect should match the two accounts, right? Unfortunately, no, since the existing cloud account already has a source anchor, and the new AD account does not have a source anchor. If a new Bret Hart account is created in AD, you’ll either see a new cloud account created (like below) or you’ll receive an error that there is a duplicate UPN:
If we open PowerShell and look at the immutable IDs of the two accounts, we can see the immutable ID for the original cloud identity (the one we restored from Azure AD) is different than the one from the new account that was created. This is the source anchor value we need to edit and add to our new AD account (to the MS-DS-ConsistencyGUID attribute):
There is another issue, though. Azure AD stores the immutableID value as Base64 and AD stores them in Hex:
If we convert the value, you can see the Hex value from our newly created AD account matches the ImmutableID in the previous screenshot for the Azure AD account. You can use free online Hex to Base64 or Base64 to Hex converters like in the screenshot below.
You can also use PowerShell to convert the Base64 value to Hex using the below syntax. Your hex value will be on the second line:
[System.Convert]::FromBase64String("Base64Value") | Format-Hex 
So, to hard match the new AD account with the existing Azure AD account, we need to convert the original immutable ID value (yuM2GvUBYEquUxh0y1PDQQ==) to Hex, and then edit the AD account ms-ds-consistencyGUID value. First, we get our Base64 ImmutableID value from the AzureAD account, and then convert that value to Hex:
Now that we have the value, we need to do one of two things – move the AD account to a non-syncing OU, or delete and recreate the AD account. If we move the user account to a non-syncing OU, it will delete the duplicate cloud identity we don’t want. Then we can edit our AD attribute and move it back to a syncing OU. So, move your account to a non-syncing OU and run a sync. This deletes the duplicate cloud identity. Then we can edit our AD attribute. Replace the mS-DS-ConsistencyGUID for the account with the Hex value from the above screenshot (CA E3 36 1A F5 01 60 4A AE 53 18 74 CB 53 C3 41):
Click OK, and then Apply to save the new value:
Move the user account back to a syncing OU, run a sync, and let’s see what happens to our cloud identity:
We can see the Sync status change in the M365 Admin GUI:
And under the user properties we can see a recent AD Connect sync:
Situation 2 – Unable to match an AD identity to an existing AAD identity
In the event, you have an existing M365 tenant with established user identities, and you’re now trying to implement Azure AD Connect, you may end up with a situation where no matter what you try, you can’t get a match between the AD and AAD identities. This is harder to reproduce, so I used some screenshots from another environment. In this case, an identity refused to match due to a duplicate conflicting value. What this really means is it’s not soft matching properly (even though everything was configured properly). It is trying to create a new cloud identity, but it can’t since the primary SMTP address is already in use (by the cloud account we are trying to match it to). So, we have a predicament. You’ll see errors in the AD Connect Synchronization Service like below:
If we remove the duplicate SMTP attribute the error is complaining about from the AD identity, it simply creates a new cloud identity, but we don’t want that. We want it to match the original cloud identity. However, we actually need to do this. The reason is since the existing cloud account we want to match to has only ever been a cloud-managed identity, it has no ImmutableID. Since our AD Account we are trying to match to the cloud identity has also never properly synced, it has no value for its mS-DS-ConsistencyGUID. Therefore, temporarily removing the conflicting attribute will allow Azure AD to generate a source anchor for the AD identity we can use. I had to blur the image below, but the top account is the newly created identity after removing the conflicting attribute.
Now that an mS-DS-ConsistencyGUID has been generated and sent down from Azure AD to AD, we can do some magic to match the identities. Remember that AD stores the value in Hex, but Azure AD uses Base64. So, we need to convert from Hex to Base64. We can also grab the Immutable ID from Azure AD from the account that was generated after we removed the conflicting attribute. This account will be removed anyway.
Record the base64 value. We will need it in a couple of steps. Next, we need to delete the cloud account that was created from AD Connect. Remove the AD account from a syncing OU so the cloud account gets removed. Then permanently delete the cloud account so it no longer exists. Remember, this is the account that was created after we removed the conflicting attribute, not our original Cloud Identity we are trying to properly match.
Next, we need to do the reverse of what we did in the first situation. This time, we need to set the immutableID value on our Azure AD Identity. We do this with the below command. Make sure you use the Base64 value we recorded earlier:
Connect-msolservice
Set-MsolUser -UserPrincipalName user@domain.com -ImmutableID <Base64ImmutableID>We check the ImmutableID value in the first command, which is empty since the identity has never been synced. We set it in the next command and then verify it:
Now, let’s move the user back into a syncing OU in Active Directory and run a delta sync. We have a hard match on the source anchor with the on-prem and cloud identities and we can see a successful sync:
We can also see the sync status changed in the M365 GUI:
