• The things that are better left unspoken

17 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?

   from RKast August 24, 2017 at 10:55 PM
   • 

     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.

     from Sander Berkouwer August 25, 2017 at 9:02 AM
     
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.

   from RKast August 25, 2017 at 3:10 PM
   • 

     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.

     from Sander Berkouwer August 27, 2017 at 11:13 AM
     
3. 
   

   Question: Where in the Metaverse do you view the mS-DS-ConsistencyGuid after synchronization?

   from Michael Berry January 8, 2018 at 1:11 AM
   • 

     Hi Michael,

     You don't actually see an attribute for objects called 'mS-DS-ConsistencyGUID' in the metaverse. As you configure Azure AD Connect, you configure it to use the mS-DS-ConsistencyGUID attribute as the SourceAnchor attribute.
     Under the hood, the sourceAnchor, or actually the sourceAnchorBinary attribute in the Metaverse get synchronized to the mS-DS-ConsistencyGUID attribute in Active Directory Domain Services.

     To see the sourceAnchor in the metaverse, perform these steps:

     • In the Start Menu, in the Azure AD Connect folder, open 'Synchronization Service'
     • In the Synchronization Service Manager, click 'Metaverse Search' in the top navigation ribbon
     • Click the 'Search' button
     • Double-click an object in the results
     • In the object's properties, you'll find the sourceAnchor and sourceAnchorBinary attributes and their values for the object

     To view the mS-DS-ConsistencyGUID attribute in Active Directory, perform these steps:

     • Open Active Directory Users and Computers (dsa.msc)
     • In the task bar, select View, then select Advanced Features'
     • Navigate to the container with the user object in the left navigation pane
     • In the main pane, double-click the user object
     • Go the the Attribute Editor tab. Scroll down to the attribute to see its value

     from Sander Berkouwer January 8, 2018 at 7:42 AM
     
4. 
   

   We actually created custom sync rules to use MS-DS-ConsitencyGUID awhile ago since a future forest migration is possible. So the Sync engine has been populating this attribute based on the OGJECTGUID at initial account creation. So our users already have values. Can we change Azure AD connect anchor now using this method? Will it just use the existing values or overwrite them? Does it really matter if it does since it was Azure AD connect that was setting the values in the first place?

   from Rob February 15, 2018 at 7:55 PM
   • 

     Hi Rob,

     Azure AD Connect's Synchronization service would detect the old value and new value to be identical, in your case.
     Then, no write action would be performed, because Azure AD Connect's logic would not deem one necessary.

     You can double-check this behavior when you use CSAnalyzer when combined with a Staging Mode server.

     from Sander Berkouwer February 16, 2018 at 10:25 PM
     
5. 
   

   Great post, this is exactly what i have been looking for. Currently we are migrating some users from domain A to domain B, the question was how we can match the onprem users with the users in AAD after migration. We are using objectGUID as source anchor at the moment. Now i will change them to mS-DS-ConsistencyGuid asap and everything should be fine 🙂 But i need to know one thing: We are using ADFS for multiple customers, if i change the source anchor from objectGUID to mS-DS-ConsistencyGuid and Azure AD Connect reconfigures my RPT on ADFS then i need to change the source anchor for all other customers too right? Otherwise they will not be able to login, is that correct? I think all customers use the objectGUID right now.

   from Markus January 28, 2020 at 4:53 PM
   • 

     Hi Markus,

     For a while now, the AD FS claims issuance rules for AD FS accommodate the use of both objectGUID and mS-DS-ConsistencyGUID.
     Pro Tip! Use the claim rules generator from ADFSHelp to get the latest claims issuance rules for your ‘Office 365 Identity Platform’ Relying Party Trust.

     from Sander Berkouwer January 28, 2020 at 10:12 PM
     
6. 
   

   thanks for the great blog.

   As far as i understand, claims flow from AD to ADFS to a Relying Party Trust (RPT). and pass 2 sets of claim rules;
   from AD called "incoming" claim rules and to an RPT, "outgoing" claim rules.

   In the solution you describe you use an outgoing claim for msdsconsistencyguid, but i dont see it anywhere in the incoming claims.
   Yet, it does work, so ADFS is able to send the msdsconsistency claim
   My question is how, what am i missing?

   cheers

   from Sander February 24, 2020 at 10:19 AM
7. 
   

   Will the PowerShell code for granting my service account permissions take into consideration the need to have the same permissions applied to the AdminSDHolder folder in AD? Otherwise I'm worried this account wouldn't be able to transition the anchor for our Domain Admins?

   from T M April 17, 2020 at 6:30 PM
   • 

     It will not.

     I feel members of the on-premises Domain Admins and Enterprise Admins group have no role in Azure AD. If any of these accounts are compromised, then the entire Active Directory domain is compromised. I consider it a best practice to not synchronize these accounts, together with any groups and user objects in the Users and Built-in containers of any Active Directory environment. Instead, create cloud administrator account and conduct your Azure AD and Microsoft 365 services with these accounts.

     For any account that was a member of any of the privileged groups (including the Print Operators and Account Operators), it's a best practice to reset AdminSDHolder to allow for proper inheritance of permissions from the parent OU.

     from Sander Berkouwer April 17, 2020 at 7:09 PM
     
8. 
   

   Hi sander – this may be answered already but i'm lost and confused so hopefully you can help.

   At present we use the mail attribute as Alternate login ID and have edited the 1st claim rule to this:

   c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"]
   query = "samAccountName={0};mail,objectGUID;{1}",
   => issue(store = "Active Directory", types = ("http://schemas.xmlsoap.org/claims/UPN", "http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID") ,
   param = regexreplace(c.Value, "(?[^\\]+)\\(?.+)", "${user}"), param = c.Value);

   How does this impact the 4 new claims rules that replace rule #1 ?

   from Martin Christopher June 3, 2020 at 11:49 AM
   • 

     Hi Martin,

     Your claim rule looks like quite an old version of the typical rule.
     You can create the latest version of the claims rules using Microsoft's Azure AD RPT Claim Rules generator.
     When you use the latest version, you'll see that currently the first rule in both cases would be:

     @RuleName = "Issue UPN"
     c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"]
     => issue(store = "Active Directory", types = ("http://schemas.xmlsoap.org/claims/UPN"), query = "samAccountName={0};mail;{1}", param = regexreplace(c.Value, "(?[^\\]+)\\(?.+)", "${user}"), param = c.Value);

     The objectGUID logic is removed from this line.
     When using objectGUID as the ImmutableID, you'll see the following claims rule:

     @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, "(?[^\\]+)\\(?.+)", "${user}"), param = c.Value);

     When using mS-DS-ConsistencyGUID, you'll see the following four claims rules for all the new logic, replacing the second claims rule of the objectGUID-style rules:

     @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, "(?[^\\]+)\\(?.+)", "${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);

     from Sander Berkouwer June 3, 2020 at 12:10 PM
     
9. 
   

   This may be a silly question, but: the service account that we need to grant permissions is the AD Connector account and not the Sync service account, right?

   from Rajaneesh Kataru June 30, 2022 at 12:43 PM
   • 

     Hi Rajaneesh,

     That is correct.
     For more information, please refer tohow to properly delegate Directory permissions to Azure AD Connect service accounts.
     If you're (still) synchronizing accounts with memberships in the Enterprise Admins, Schema Admins, Domain Admins, Account Operators, Server Operators, Print Operators and/or Backup Operators groups in Active Directory, please also refer to how to solve Azure AD Connect synchronization errors for objects with adminCount attributes set to 1.

     from Sander Berkouwer July 1, 2022 at 9:25 AM