Azure AD Connect: objectGUID vs. mS-DS-ConsistencyGuid, Part 1

Reading Time: 6 minutes

The Azure AD Connect Team has decided to move Azure AD Connect’s default source anchor attribute in on-premises Active Directory Domain Services (AD DS) environments from objectGUID to mS-DS-ConsistencyGuid for user objects in Azure AD Connect version 1.1.553.0, and up.

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 AD Connect Upgrad - Configuration complete - Azure Active Directory is configured to use AD attribute objectGUID as the source anchor attribute. (click for original screenshot)

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

The source anchor attribute helps Azure AD Connect to perform a hard match between on-premises objects in Active Directory Domain Services (AD DS) to objects in Azure Active Directory.

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:

TableAzureADConnectSourceAnchorHistory

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

With the possibility for Azure AD Connect to synchronize multiple on-premises Active Directory Domain Services (AD DS) environments, a challenge emerges:

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.

 

How does mS-DS-ConsistencyGuid help?

When your organization already faced the challenges above, you may have already switched from objectGUID to mS-DS-ConsistencyGuid, mS-DS-SourceAnchor or even EmployeeID, using Mark Renoden’s guidance or using Roelf Zomerman’s guidance.

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:

  1. 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.
  2. 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.
  3. 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:

The 'Reset Azure AD and AD FS Trust' option in Azure AD Connect (click for original screenshot)

 

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.

Further reading

MS-DS-Consistency-Guid attribute
Object-Guid attribute
Choosing a sourceAnchor for Multi-Forest Sync with AAD Connect – Part 5, Using mS-DS-ConsistencyGuid
Migrating ‘SourceAnchor’ from ‘ObjectGUID’ using new AAD Connect 1.1.524.0
Office 365 – Why You Need to Understand ImmutableID
ImmutableID – mS-DS-ConsistencyGuid – ADConnect

12 Responses to Azure AD Connect: objectGUID vs. mS-DS-ConsistencyGuid, Part 1

  1.  

    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.

  2.  

    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.

  3.  

    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?

  4.  

    How we can do this ?

    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.

  5.  

    Great article!

    • Thanks, Toon!

       
  6.  

    Hi Sander, Thanks for the great post.
    When migrating Azure AD Connect from 1.4 to v2.x on a new server, the ADSyncDocumenter comparison tool lists the source anchor for Groups as changing from objectguid to ms-ds-consistencyguid, which I undertand is now the default.

    Or more specifically, it lists the new value being: IIF(IsPresent([mS-DS-ConsistencyGuid]),[mS-DS-ConsistencyGuid],[objectGUID])

    Is there any risk taking the new AAD Connect instance out of staging mode on the new server? We can't seem to find a way to change the source anchor for groups back to objectGuid (if we did this, the 2 configs would be the same).

    Cheers,
    Giovanni

    • Hi Giovanni,

      With Azure AD Connect 1.5.18.0, Azure AD Connect switched from objectGUID to mS-DS-ConsistencyGUID as the source anchor for group objects. Of course, at the initial Import step for Active Directory, no value for the mS-DS-ConsistencyGUID attribute is not present, as it is written during the first Export step towards Active Directory. Permissions and custom synchronization rule conflicts may get in the way. If there is something in the way, the objectGUID attribute is still perfectly capable of acting as the source anchor attribute (the end-to-end attribute that ties the Azure AD object and Active Directory object together and that offers a way to tie the two objects together even when your Azure AD Connect installations are completely lost and need to be rebuilt.

      I don't expect any problems with this rule change.
      I have not heard of any people with problems with this rule change.

       
  7.  

    Hi Sander,
    https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/reference-cloud-sync-faq#does-cloud-sync-support-writeback-of-ms-ds-consistencyguid-for-any-object-

    'Does cloud sync support writeback of ms-ds-consistencyGUID for any object?
    No, cloud sync doesn't support writeback of ms-ds-consistencyGUID for any object (including user objects).'

    Do you happen to know what this means? As far as I understand Azure AD Connect Sync stamps the ms-ds-consistencyGUID on AD accounts. But it seems(?) to me, at least the wording MS chose, that Azure AD Connect Cloud Sync doesn't do this?

    And if so, is the ms-ds-consistencyGUID not used anymore with Azure AD Connect Cloud Sync (at least not stamped on new user AD accounts anymore)?

  8.  

    Sander,
    Guess I found an sort of answer here:
    https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/plan-cloud-sync-topologies

    'The source anchor for objects is chosen automatically. It uses ms-DS-ConsistencyGuid if present, otherwise ObjectGUID is used.'

    So it seems that Azure AD connect cloud sync .. ehhh Microsoft Entra Cloud Sync does not populate the ms-DS-ConsistencyGuid anymore and reverts to the ObjectGUID. Guess this is due to limited permissions for the cloud agent? Interesting enough though .. the ms-ds-consistencyGUID seemed to be a solid thing.

  9.  

    Hi again, sorry for (my last) spamming post but this seems also interesting because of this blogpost specifically about the introduction of the mS-DS-ConsistencyGuid attribute.

    I opened a topic about the consistency of writing the mS-DS-ConsistencyGuid word and it attracted some information maybe worthwhile to notice (but then I'm not deep into this matter and might be known already).

    https://github.com/MicrosoftDocs/entra-docs/issues/184

    'Cloud sync does not support writeback of ms-ds-consistencyGUID for any object. Unlink traditional AD connect, for any given on-premises AD User object whose ms-DS-ConsistencyGuid attribute isn't populated, Azure AD Connect writes its objectGUID value back to the ms-DS-ConsistencyGuid attribute in on-premises Active Directory. After the ms-DS-ConsistencyGuid attribute is populated, Azure AD Connect then exports the object to Azure AD.

    For inter forest object move, the ms-DS-ConsistencyGuid attribute needs to be manually populated during migration. For example: You would create the bbb\user in the forest they are moving to then copy over the objectGUID value from aaa\user to bbb\user's ms-DS-ConsistencyGuid attribute in on-premises Active Directory).'

    So it seems the inter forest object move has been impacted with this behavior. Although it might seem to me I never would encounter these situations it's nice to see this additional information. Thanks again 🙂

leave your comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.