Troubleshooting Azure Active Directory Sync error related to conflicted objects

Hello,

As you know, one of the things I enjoy doing in my lab, is to break things, and once they are broken enough, I start fixing them up. Sound quite masochist but that is one of the great ways to learn.

So, I was trying to break the relationship between an account in my on-premise environment and my Azure AD and try to re-establish it. However, it is not simple as I expected because you cannot do this in a proper way. Here is what I did to break everything and eventually fix them up.

The thing with Azure AD and On-Prem environment is that, once you remove an object, it is also removed from Azure AD. So, I need to keep both objects in place but with different ‘sourceanchor’. This attribute is the attribute that AAD use to link two users together. What I did to reproduce the issue was like this:

  1. Uninstalling Azure AD Connect
  2. Remove the user from On-Premise environment
  3. Recreated the user with same UPN etc.
  4. Installed Azure AD Connect again.

By this time, the issue was reproduced, and I had an error like this in my ‘Sync Service’:

The error was clear:

“unable to update this object because the following attributes associated with this object have values that may already be associated with another object in your local directory services.”

So why it happened? Here is what happens in the background that throws this error. Let’s say we have an account in our On-Premise AD with UPN of Mahdi@tintin.tt , then I uninstalled the Azure AD Connect. The relationship between the On-Premise environment and AAD was broken at that time and nothing were synced. Then I removed the user from AD, recreated it with same UPN of Mahdi@tintin.tt , and then installed Azure AD Connect. So, the question is, why the same user is not associated with the old user who is in Azure? The answer for that lies under the concept of anchors. Once a user is created in AD, Azure AD Connect will pick it ‘ObjectGUID’ or ‘MS-DS-Consistency-Guid’ (depending on your configuration) and use it as an Anchor to link the user from AD to the user from AAD. So, this is how AAD will always keep the same user to the same identity in Cloud and apply delta updates on it.

When I deleted the account and recreated it, basically I destroyed it’s GUID (GUIDs are unique). Then I tried to synchronize the user from On-Premise to AAD, the AAC could not link them together because their GUID is different. So, it tries to match the UPN to an identity with same GUID who has not UPN in cloud but since they both have the same UPN, it will not link them together. This is due to the fact that AAD consider both of them as different identities and not a single identity which must be linked.

You can verify both their anchors to see if they are linked together or not. Basically, the ‘sourceanchor’ in Metaverse must be same as the ‘ImmautableID’ in Azure AD. If they are different, they will not get synced. The image below shows the difference between these two versions:

But let’s say we are in this situation and we want to fix this. The solution is quite simple. You must export the ‘ImmutableID’ of the user from the cloud and import it on ‘MS-DS-Consistency-Guid’  attribute of the On-Premise user account. As shown in image above, you can export this value by using Get-MsolUser by passing the UPN and selecting the ‘ImmutableID’. Once we have this value, we need to pass this value to a converter so that we can have the value in Base64. The PowerShell code for that is as follows:

[system.convert]::FromBase64String(faownwnEgkSGiAaIxFsyjA==) | %{$a += [System.String]::Format({0:X}, $_) +  };$result = $null;$result = $a.trimend();$result

 

And the command will return a value for you:

In next step, you need to copy this value to the ‘MS-DS-Consistency-Guid’ attribute of the user account:

Once it is done, it is better to run a Sync Run to see if attribute in Metaverse is populated. Image below shows that the new value has been written to Metaverse:

Once the correct value is written in Metaverse, we can go ahead and do the export to our Azure AD because both users in On-Prem and Azure has the same anchor and they can be linked together:

Do not forget that here I have ‘MS-DS-Consistency-Guid’ configured in place, if in your environment you are still using ‘ObjectGUID’, you will not be able to do that because ObjectGUID is read-only and you cannot populate it. In that case it is better to re-install AAC and choose ‘MS-DS-Consistency-Guid’ as the source anchor.

 

Happy syncing :)