When you’ve been using Azure AD Connect to synchronize objects between your on-premises Active Directory Domain Services (AD DS) environment(s) and Azure Active Directory, and you upgrade to this version, or any version beyond from a previous version, you’ll be notified of this change with a notice on the Configuration complete screen:

Azure Active Directory is configured to use AD attribute objectGUID as the source anchor attribute. It is strongly recommended that you let Azure manage the source anchor for you. Please run the wizard again and select Configure Source Anchor.Learn more

About Source Anchors

It is recommended to use an attribute as a source anchor that doesn’t change throughout the lifecycle of an Active Directory object and is unique to the object. Because people get married, get divorced, change their names, etc. the userPrincipalName, and mail attributes cannot be picked as the source anchor attribute in Azure AD Connect. (and also, because source anchors may not contain special characters, like the @-sign).

Before Azure AD Connect version 1.1.524.0, Azure AD Connect (but also Azure AD Sync and DirSync) defaulted to the objectGUID attribute for objects as the source anchor. Azure AD Connect version 1.1.553.0, and beyond, defaults to the mS-DS-ConsistencyGuid for user objects, but objectGUID for groups and computer objects.

The table below provides an overview:

This begs the question: What’s wrong with using ObjectGUID as the source anchor?

What’s wrong with objectGUID?

objectGUID is an attribute for on-premises Active Directory objects, that is written to with a random value when the object is created. From there on, it can no longer be changed. It’s immutable, even for Active Directory itself.

You’d think this makes for a pretty decent source anchor, but there two challenges:

The Cross-forest Migration Challenge

How do we cope with migrating a user object from one Active Directory forest, to another, when the person associated with the user account enjoys the benefits of Azure Active Directory?

When a user object is migrated from one Active Directory forest, to another, it is reborn, and, thus, receives a different value for objectGUID. Azure AD Connect will not be able to perform a hard match and the person may receive no mailbox, a fresh new mailbox, or worse, access to someone else’s mailbox…

The Accidentally Deleted Challenge

The second issue with using objectGUID as the source anchor for Azure AD Connect is that it complicates undelete of (accidentally) deleted user objects in on-premises Active Directory Domain Services (AD DS) environments in scope for synchronization.

While the use of the Active Directory Recycle Bin feature is highly recommended (Azure AD Connect provides a notice when this feature is not enabled), it’s not possible to enable it in every environment. While enabled, though, it adds another 180 days time-out, by default, to the garbage collection process on each of your Domain Controllers, on top of the default 180 days tombstone lifetime.

In other Active Directory Domain Services (AD DS) environments, though, the tombstone lifetime may still be set at 60 days. When these Active Directory forests were first setup, admins leveraged Domain Controllers running Windows Server versions prior to Windows Server 2003 with Service Pack 1. In the time since its inception, the tombstone lifetime was never set to 180 days, although Microsoft changed its recommendation.

When you reanimate an object beyond the tombstone lifetime, or in other rare cases, the object is recreated with its former attributes, except for objectGUID… Since this is a system-generated value set at creation date, the object is reborn with a different value for its objectGUID attribute.

The magic in Azure AD Connect version 1.1.553.0, and beyond, is the introduction of the ability to automatically switch from objectGUID to mS-DS-ConsistencyGuid.

When you select mS-DS-ConsistencyGuid , Azure AD Connect will perform the following actions:

In organizations with Active Directory Federation Services (AD FS) and the ‘Office 365 Identity Platform’ (or urn:federation:MicrosoftOnline) Relying Party Trust (RPT), Azure AD Connect will update the AD FS Issuance Transform Rules for this RPT to accommodate the use of mS-DS-ConsistencyGuid.

On the first synchronization cycle, Azure AD Connect will check the mS-DS-ConsistencyGuid attribute of user objects in scope. When these attributes are empty, Azure AD Connect will update the attributes with the value of the objectGUID attribute.

On the second synchronization cycle, Azure AD Connect will synchronize the user objects in scope with filled mS-DS-ConsistencyGuid attributes to Azure Active Directory.

Now, when you migrate a user object from one on-premises Active Directory Domain Services (AD DS) environment, to another, and both environments are in (future) scope of Azure AD Connect, the value for the objectGUID attribute of the user object changes, but the value for the mS-DS-ConsistencyGuid attribute remains the same. With mS-DS-ConsistencyGuid as its source anchor attribute, Azure AD Connect is able to hard match the Active Directory user object with the Azure Active Directory user object, as if nothing happened.

The same thing happens when you reanimate a user object in the on-premises Active Directory Domain Services (AD DS) environment: the value for the objectGUID attribute of the user object changes, but the value for the mS-DS-ConsistencyGuid attribute remains the same.

What you need to know

I have already scattered some tidbits throughout this blogpost on what you may, and may not expect from this change. I’ve compiled a list below for your convenience:

The source anchor setting is a per-Azure AD Connect setting. When you change the source anchor attribute on your actively synchronizing Azure AD Connect installation, you should also change the source anchor attribute on the Staging Mode Azure AD Connect installation(s).

The mS-DS-ConsistencyGuid attribute may not be in use by another application throughout each of the on-premises Active Directory Domain Services (AD DS) environments you have or intend to have in scope for Azure AD Connect.

Custom-managed Azure AD Connect service account(s) may not have permission to write to the mS-DS-ConsistencyGuid attribute of user objects in your on-premises Active Directory Domain Services (AD DS) environment(s). You will need to grant this permission manually in (each of) the Active Directory Domain Services environment(s) in scope.

The switch from objectGUID to mS-DS-ConsistencyGuid as the source anchor in Azure AD Connect is (currently) only available for user objects, not for groups or computer objects.

When you leverage Active Directory Federation Services (AD FS) as the Azure AD authentication scenario with Azure AD Connect, you will need direct network connections using TCP80, TCP443 and TCP5985 between your Azure AD Connect installation and the primary AD FS Server, when you switch from objectGUID to mS-DS-ConsistencyGuid as the source anchor attribute.

When you make the switch through Azure AD Connect, it is no longer a good idea to reset the ‘Office 365 Identity Platform’ (or urn:federation:MicrosoftOnline) Relying Party Trust (RPT) by deleting it on the AD FS Primary Server and then recreating it using the Convert-MSOLDomaintoFederated PowerShell Cmdlet. Instead, use the Reset Azure AD and AD FS Trust option in Azure AD Connect:

Concluding

Join me for part 2 of this series, where I show you the exact changes in Active Directory Federation Services’ Issuance Transform Rules and a script to grant a custom Azure AD Connect service account permissions to write the mS-DS-ConsistencyGuid attribute in your on-premises Active Directory Domain Services (AD DS) environments.

Hi,
How AAD Connect transforms employeeID(from AD) as SourceAnchor to ImmutableID(to Azure AD)? In case of ObjectGUID as SourceAnchor , it will converts sourceAnchor to base64string and stores in ImmutableID of the corresponding user.

This appears to be exactly what I have been looking for. I have multi forest , hybrid , O365 CRM environment That I have been performing migrations, Domain consolidation and coming up includes the O365 CRM users that I had concerns with how that was to happen.

fromFrank Kirk August 29, 2017 at 9:51 PM

This is a juicy post Sander. Lots of useful tidbits of info.

One question though. If we set the source anchor to EmployeeID for example and decide to change this to ms-DS-ConsistencyGuid via uninstalling and reinstalling AD Connect, does this mean we have to start all over? like permanently removing all synced accounts in Azure and Azure recycle bin and doing a new initial sync?

OR

can we just resync everything normally after uninstalling and reinstalling AD Connect with the new sourceAnchor?

Custom-managed Azure AD Connect service account(s) may not have permission to write to the mS-DS-ConsistencyGuid attribute of user objects in your on-premises Active Directory Domain Services (AD DS) environment(s). You will need to grant this permission manually in (each of) the Active Directory Domain Services environment(s) in scope.

Archives

Categories

The information on this website is provided for informational purposes only and the authors make no warranties, either express or implied. Information in these documents, including URL and other Internet Web site references, is subject to change without notice. The entire risk of the use or the results from the use of this document remains with the user.Active Directory, Microsoft, MS-DOS, Windows, Windows NT, and Windows Server are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. All other trademarks are property of their respective owners.