#AzureAD Connect and the on-premises AD Recycle Bin: What do you need to know about the sourceAnchor attribute

Starting from Windows Server 2008 R2, we had the really good option to enable Active Directory Recycle Bin. After all these years you should be familiar with that option, since we talk often about this topic for that last… 8 years.

If you just want to refresh your memory and learn about the on-premises AD Recycle Bin, you can take a look at this article.

But wait: these days is common to sync our on-premises AD objects to the cloud using AAD Connect, but how this new feature is related to our “local” AD Recycle BIn?

The story here is really simple: If you accidentally deleted an on-premises AD user object and restore it using AD Recycle Bin, Azure AD restores the corresponding Azure AD user object. So lets dig a little bit deeper on this topic and check all the different options that we get:

• If you accidentally deleted an on-premises AD user object, the corresponding Azure AD user object will be deleted in the next sync cycle. By default, Azure AD keeps the deleted Azure AD user object in soft-deleted state for 30 days.

• If you have on-premises AD Recycle Bin feature enabled, you can restore the deleted on-premises AD user object without changing its sourceAnchor value. When the recovered on-premises AD user object is synchronized to Azure AD, Azure AD will restore the corresponding soft-deleted Azure AD user object.

• If you do not have on-premises AD Recycle Bin feature enabled, you may be required to create an AD user object to replace the deleted object. If Azure AD Connect Synchronization Service is configured to use system-generated AD attribute (such as ObjectGuid) for the Source Anchor attribute, the newly created AD user object will not have the same Source Anchor value as the deleted AD user object. When the newly created AD user object is synchronized to Azure AD, Azure AD creates a new Azure AD user object instead of restoring the soft-deleted Azure AD user object. So practically you create a brand new object, without being possible to restore the original AD object: it’s just a new account. Remember: By default, Azure AD keeps deleted Azure AD user objects in soft-deleted state for 30 days before they are permanently deleted. However, administrators can accelerate the deletion of such objects. Once the objects are permanently deleted, they can no longer be recovered, even if on-premises AD Recycle Bin feature is enabled.

sourceAnchor
As we already said above, with AD Recycle Bin you can restore an object without changing its sourceAnchor value. The sourceAnchor attribute is defined as an attribute immutable during the lifetime of an object. It uniquely identifies an object as being the same object on-premises and in Azure AD. The attribute is also called immutableId and you’ll often see that we use both names. So practically this attribute cannot be changed, and for this reason you should have a clear idea on how things work here.

This attribute is used during the following cases:

• When a new sync engine server is built (a new sync between your on-premises AD and Azure AD), or rebuilt after a disaster recovery scenario, this attribute links existing objects in Azure AD with objects on-premises.
• If you move from a cloud-only identity to a synchronized identity model, then this attribute allows objects to «hard match» existing objects in Azure AD with on-premises objects.
• If you use federation, then this attribute together with the userPrincipalName is used in the claim to uniquely identify a user.

It’s really important to select the appropriate attribute, since we said that it cannot be changed:

• Be less than 60 characters in length
  • Characters not being a-z, A-Z, or 0-9 are encoded and counted as 3 characters
• Not contain a special character: \ ! # $ % & * + / = ? ^ ` { } | ~ < > ( ) ‘ ; : , [ ] » @ _
• Must be globally unique
• Must be either a string, integer, or binary
• Should not be based on user’s name, sometimes we change the user name!! 
• Should not be case-sensitive and avoid values that may vary by case
• Should be assigned when the object is created

Remember: The sourceAnchor attribute is case-sensitive. A value of “chrisSpanougakis” is not the same as “chrisspanougakis”.

If you have a single forest on-premises, then the attribute you should use is objectGUID. This is also the attribute used when you use express settings in Azure AD Connect and also the attribute used by the old DirSync. Generally speaking, there are a lot of cases that is recommended to use the objectGUID attribute, even when we use multiple forests and we do not move users between forests.

Is it possible to change the sourceAnchor attribute?
No. As soon as you create the object and you sync it to Azure AD, it’s not possible to change it anymore. If you want to change it, you should uninstall and reinstall Azure AD Connect. If you install another Azure AD Connect server, then you must select the same sourceAnchor attribute as previously used. If you’ve been using DirSync and move to Azure AD Connect, then you must use objectGUID since that is the attribute used by DirSync. If the value for sourceAnchor is changed after the object has been exported to Azure AD, then Azure AD Connect sync throws an error and does not allow any more changes on that object before the issue has been fixed and the sourceAnchor is changed back in the source directory.

By default, Azure AD Connect (version 1.1.486.0 and older) uses objectGUID as the sourceAnchor attribute. ObjectGUID is system-generated. You cannot specify its value when creating on-premises AD objects. But fortunately, there is a workaround for this: you must use a configurable AD attribute (for example, msDS-ConsistencyGuid) as the sourceAnchor attribute.

You need to use Azure AD Connect (version 1.1.524.0 and after) in order to be able to use the msDS-ConsistencyGuid attribute. For on-premises AD User objects whose msDS-ConsistencyGuid attribute isn’t populated, Azure AD Connect writes its objectGUID value back to the msDS-ConsistencyGuid attribute in on-premises Active Directory. After the msDS-ConsistencyGuid attribute is populated, Azure AD Connect then exports the object to Azure AD.

How we enable the ConsistencyGuid feature?
When installing Azure AD Connect with Express mode, the Azure AD Connect wizard automatically determines the most appropriate AD attribute to use as the sourceAnchor attribute. Since we talk here about a fresh installation of Azure AD Connect, the wizard checks the state of the msDS-ConsistencyGuid attribute in your on-premises Active Directory. If the attribute isn’t configured on any object in the directory, the wizard uses the msDS-ConsistencyGuid as the sourceAnchor attribute.

But: If the attribute is configured on one or more objects in the directory, the wizard concludes the attribute is being used by other applications and is not suitable as sourceAnchor attribute, In this case, the wizard selects to use objectGUID as the sourceAnchor attribute.

Once the sourceAnchor attribute is decided, the wizard stores the information in your Azure AD tenant. The information will be used by future installation of Azure AD Connect. Practicall when the wizard finishes, you should see something like this:

If you do a custom installation of Azure AD Connect, you have the option to select how users will be identified in Azure AD:

Select the first option if you want Azure AD to pick the attribute for you. If you select this option, Azure AD Connect wizard applies the same logic as we described above, during the Express installation of Azure AD Connect. The second option will let you select a specific attribute.

Change the attribute on an a existing installation
If you have an existing Azure AD Connect deployment which is using objectGUID as the Source Anchor attribute, you can switch it to using ConsistencyGuid.

• Start the Azure AD Connect wizard and click Configure to go to the Tasks screen.

• Select the Configure Source Anchor task option and click Next.

Thanks for your time!