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

This entry is part 2 of 3 in the series Azure AD Connect: objectGUID vs. mS-DS-ConsistencyGuid

In the first part of this series, I’ve explained how Azure AD Connect version 1.1.553.0 and beyond allows you to switch from objectGUID to mS-DS-ConsistencyGuid as the source anchor attribute, the benefits of doing so and what you may and may not expect when you make the switch.

In this second part, I’ll share the changes Azure AD Connect makes in its synchronization rules, in the Active Directory Federation Services (AD FS) claims transformation rules and a PowerShell script that you can use to grant your custom-managed Azure AD Connect service account permissions to write the mS-DS-ConsistencyGuid attribute in your on-premises Active Directory Domain Services (AD DS) environments.

 

Determining the version of Azure AD Connect

Now, the first thing you’d want to find out is your version of Azure AD Connect, since the embrace of the mS-DS-ConsistencyGuid attribute as the source anchor is only possible on Azure AD Connect installations running version 1.1.553.0 and up. Also, versions 1.1.561.0 and up of Azure AD Connect implement the change automatically, when you perform a fresh installation of Azure AD Connect.

Perform these steps to determine your version of Azure AD Connect:

  • Log on interactively to the Windows Server installation that runs Azure AD Connect.
  • Right-click the Start button on the bottom left corner of your screen, or press Win + X simultaneously.
  • Select Programs and Features from the top of the context menu.

Programs and Features (click for original screenshot)

  • In the list below Uninstall or change a program look into the Version column for Microsoft Azure AD Connect.

Perform these steps for all Azure AD Connect installation(s) in your infrastructure. Don’t forget to check and upgrade your Staging Mode servers.

 

Determining the attribute used as the source anchor for user objects in Azure AD Connect

Perform these steps to determine the current attribute used as source anchor in your Azure AD Connect installation(s):

  • Log on interactively to the Windows Server installation that runs Azure AD Connect.
  • Open Azure AD Connect using the link on the desktop or by searching for (part of) its name in the Start Screen and then clicking it in the search results.
  • Click the Configure button on the Welcome to Azure AD Connect screen.
  • Click on View current configuration in the Additional tasks screen.
  • Click Next.

Azure AD Connects Review Your Solution screen (click for original screenshot)

  • The attribute listed as the Source Anchor for user objects is listed underneath SOURCE ANCHOR in the Synchronization Settings area in the Review Your Solution screen.

Changes in Azure AD Connects Configuration

The following changes are observed in Azure AD Connects synchronization rules after you switch from objectGUID to mS-DS-ConsistencyGuid as the source anchor attribute in Azure AD Connect:

Global Settings

The Microsoft.SynchronizationOption.AnchorAttribute setting is changed from objectGUID to mS-DS-ConsitencyGuid

Metaverse configuration

The Source fields for the sourceAnchor and sourceAnchorBinary attributes for the Metaverse person have been updated.

AD Connector Configuration

The import flow component for the mS-DS-ConsitencyGUID attribute is enabled next to the previously enabled export flow.

Attribute flows for the AD Connector

The end-to-end import flow for the SourceAnchorBinary attribute for the contact object has been updated.

The end-to-end import flows for the SourceAnchor and SourceAnchorBinary attributes for the inetOrgPerson object has been updated.

The end-to-end import flows for the SourceAnchor and SourceAnchorBinary attributes for the user object has been updated.

The end-to-end export flow for the mS-DS-ConsistencyGuid attribute for the user object has been added.

The inbound provisioning rules have been updated to use the mS-DS-ConsistencyGuid as the Source Attribute.

Attribute flows for the Azure AD Connector

The end-to-end export flows for the dn and sourceAnchor attributes for the contact object have been updated.

The end-to-end export flow for the dn and sourceAnchor attributes for the user object has been added.

 

This is achieved through changes in the following synchronization rules:

  • In from AD – InetOrgPerson AccountEnabled
  • In from AD – InetOrgPerson Common
  • In from AD – InetOrgPerson Join
  • In from AD – User AccountEnabled
  • In from AD – User Common
  • In from AD – User Join
  • Out to AD – User ImmutableId
  • Out to AD – User Join SOAInA

… and a bunch of precedence changes, of course.

 

Granting your Azure AD Connect Service Account permissions to write to the mS-DS-ConsistencyGuid attribute

Use the following lines of PowerShell to grant a custom-managed service account for Azure AD Connect the permissions to write to the mS-DS-ConsistencyGuid attribute throughout your on-premises Active Directory Domain Services (AD DS) environment, when you follow the rules for least administrative privileges for service accounts:

#Specify the Base DN from where you d want to propogate:
$DN = “OU=Service accounts,OU=my,DC=domain,DC=tld”

#Specify the service acocunt itself
$Account = “domain\sa_aadconnect”

#Build the command line using dsacls.exe
$cmd = “dsacls ‘$DN‘ /I:S /G ‘`”$Account`”:RPWP;`”mS-DS-ConsistencyGuid`”;user'”

#Run the command line
Invoke-Expression $cmd

Note:
Run the above PowerShell script in all Active Directory Domain Services (AD DS) environments in scope of Azure AD Connect synchronization.

Note:
If you want to granularly grant permissions to the service account, create scripts to target each of the Organizational Units (OUs) in scope of Azure AD Connect synchronization, on the highest level, or use the guidance here.

 

Changes in Active Directory Federation Services (AD FS) claims rules with the mS-DS-ConsistencyGUID attribute as Source Anchor

When you switch from objectGUID to mS-DS-ConsistencyGuid as the source anchor attribute, you’ll see that Azure AD Connect makes the following changes to the Active Directory Federation Services (AD FS) claims rules, when you manage AD FS through Azure AD Connect.

The following claims issuance rule when using ObjectGUID as the Source Anchor:

@RuleName = “Issue Immutable ID”

c:[Type == “http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname“]

=> issue(store = “Active Directory”, types = (“http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID“), query = “samAccountName={0};objectGUID;{1}”, param = regexreplace(c.Value, “(?<domain>[^\\]+)\\(?<user>.+)“, “${user}”), param = c.Value);

Is replaced with the following four claims issuance rules to accommodate mS-DS-ConsistencyGuid as the Source Anchor:

@RuleName = “Query objectguid and msdsconsistencyguid for custom ImmutableId claim”

c:[Type == “http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname“]

=> add(store = “Active Directory”, types = (“http://schemas.microsoft.com/ws/2016/02/identity/claims/objectguid“, http://schemas.microsoft.com/ws/2016/02/identity/claims/msdsconsistencyguid), query = “samAccountName={0};objectGUID,mS-DS-ConsistencyGuid;{1}”, param = regexreplace(c.Value, “(?<domain>[^\\]+)\\(?<user>.+)“, “${user}”), param = c.Value);

 

@RuleName = “Check for the existence of msdsconsistencyguid”

NOT EXISTS([Type == “http://schemas.microsoft.com/ws/2016/02/identity/claims/msdsconsistencyguid“])

=> add(Type = “urn:federation:tmp/idflag”, Value = “useguid”);

 

@RuleName = “Issue msdsconsistencyguid as Immutable ID if it exists”

c:[Type == “http://schemas.microsoft.com/ws/2016/02/identity/claims/msdsconsistencyguid“]

=> issue(Type = “http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID“, Value = c.Value);

 

@RuleName = “Issue objectGuidRule if msdsConsistencyGuid rule does not exist”

c1:[Type == “urn:federation:tmp/idflag”, Value =~ “useguid”]
&& c2:[Type == “http://schemas.microsoft.com/ws/2016/02/identity/claims/objectguid“]

=> issue(Type = “http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID“, Value = c2.Value);

 

Concluding

Now we have a good understanding of what the switch from objectGuid to mS-DS-ConsistencyGuid as the source anchor attribute actually entails, it’s time to perform it.

Join me for Part 3, where I show you how to perform the switch, and do all the work, so you won’t forget any steps.

Series Navigation

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

4 Responses to Azure AD Connect: objectGUID vs. mS-DS-ConsistencyGuid, Part 2

  1.  

    Thanks for This Great post. If we manual configure adfs and federate a domain, do we need to delete all claim rules on the o365 relying party and add your 4 claim rules?

    • I do not recommend changing the ‘Office 365 Identity Platform’ RPT in AD FS manually.
      In troubleshooting scenarios, often the process is to recreate the RPT by deleting it and running the Convert-MSOLDomainToFederated PowerShell Cmdlet. When the RPT is ‘under management’ of Azure AD Connect, you can recreate the RPT using the ‘Change user sign in’ option in Azure AD Connect, recreating all its special rules (there are more than the ones above).

      I started believing that when an organization has (recent versions of) both AD FS and Azure AD Connect, the best things you can do is to configure Azure AD Connect to manage AD FS and configure Azure AD Connect Health on the AD FS Servers and Web Application Proxies. You don’t need to setup AD FS through Azure AD Connect to achieve this. You’ll still be able to segregate responsibilities and duties between the two teams, but you’ll need to communicate more. This way, the organization is able to achieve two goals: The AD FS functionality is extended. The AD FS infrastructure is monitored.

       
  2.  

    Thanks for your answer. Do you recommend Express over Custom setup? Cause Express configures everything for you with best recommended settings and permissions for sync account.

    • I feel the consultant in me rear its ugly head with an ‘It depends’ answer. 😉

      I doubt Express Settings are the best settings for each environment. I feel they are the recommended practice for most organizations and always work, but there are some pieces of configuration you won’t get when you use the Express Settings, like the ability to use a (group) Managed Service Account (gMSA), reuse current Microsoft SQL Server investments and admin privileges assigned to groups from the current delegation model.

       

leave your comment