Partager via

Choosing a sourceAnchor for Multi-Forest Sync with AAD Connect - Part 5, Using mS-DS-ConsistencyGuid

  • Article

Update 25th May 2017:- As of AAD Connect May 2017 release, version 1.1.524, the default sourceAnchor used by the setup wizard is mS-DS-ConsistencyGuid. This renders most of this blog post series moot but it will be maintained for reference.

 

This blog post series is based upon and tested with AAD Connect, December 2016 release, version 1.1.380.0. Test all deployment designs before production implementation.

Table of Contents

Part 1, Introduction

Part 2, Lab Setup

Part 3, An Aside on EmployeeID

Part 4, Using msDS-SourceAnchor

Part 5, Using mS-DS-ConsistencyGuid

Part 6, Moving off objectGuid

Part 7, Migrating Users

Green Fields Deployment with mS-DS-ConsistencyGuid

The steps to configure mS-DS-ConsistencyGuid as the sourceAnchor are almost identical to those for msDS-SourceAnchor. For this reason, I'll be less verbose than last than my last post and just highlight the configuration differences.

The rule logic has to be slightly different because mS-DS-ConsistencyGuid and msDS-SourceAnchor have different attribute syntax (data types) in Active Directory. For write-back to on-premises Active Directory objects, we will use SourceAnchorBinary to populate mS-DS-ConsistencyGuid

Just as I did in the last post, a new deployment starts by choosing mS-DS-ConsistencyGuid in the AAD Connect setup wizard -

sa21

Note: It is unsupported to edit the built-in rules. All you can do is copy them which disables the original.

Notice that the lowest precedence on these rules is 100. Starting from a precedence value of

(100 - (2 x number_of_forests)) we'll number each new rule

In my example, this value will be (100 - (2 x 2)) = 96

I'll have

  • In from AD - User Join Custom = 96
  • In from AD - User Join Custom = 97
  • In from AD - mS-DS-ConsistencyGuid = 98
  • In from AD - mS-DS-ConsistencyGuid = 99

Modifying User Join Rules

Note the precedence value you're up to

Click Edit and then click Yes when prompted to copy the rule

Provide a meaningful Name (e.g. In from AD - User Join Custom)

Set the Precedence

Click Next twice

On the Join Rules page, in the existing join rule, change the Source Attribute to mS-DS-ConsistencyGuid and the Target Attribute to sourceAnchorBinary

On the Join Rules page, click Add group

On the Join Rules page, in the new join rule, change the Source Attribute to objectGuid and the Target Attribute to sourceAnchorBinary

sa22

Click Next

On the Transformation page, edit the second rule so that the FlowType is Expression, Target Attribute is sourceAnchor and the source is

 IIF(IsPresent([mS-DS-ConsistencyGuid]),IIF(IsString([mS-DS-ConsistencyGuid]),CStr([mS-DS-ConsistencyGuid]),ConvertToBase64([mS-DS-ConsistencyGuid])),IIF(IsString([objectGUID]),CStr([objectGUID]),ConvertToBase64([objectGUID])))

On the Transformation page, add a third rule so that the FlowType is Expression, Target Attribute is sourceAnchorBinary and the source is

 IIF(IsPresent([mS-DS-ConsistencyGuid]),[mS-DS-ConsistencyGuid],[objectGUID])

sa23

Click Save

If prompted with an Expression Warning, click Yes

Repeat for each additional Forest being synchronised

Overriding User AccountEnabled and User Common Rules for sourceAnchor

The process for creating a new rule to override each of the other rules is -

Note the precedence value you're up to

Click Add New Rule

Provide a meaningful Name (e.g. In from AD - mS-DS-ConsistencyGuid)

Set the Connected System to the Forest you're configuring for

Set the Connected System Object to user

Set the Metaverse Object Type to person

Set the Link Type to Join

Set the Precedence

Click Next three times

On the Transformations page, click Add transformation

Set FlowType to Expression

Set Target attribute to sourceAnchor

Change the source expression to

 IIF(IsPresent([msExchRecipientTypeDetails]),IIF([msExchRecipientTypeDetails]=2,NULL,IIF(IsPresent([mS-DS-ConsistencyGuid]),IIF(IsString([mS-DS-ConsistencyGuid]),CStr([mS-DS-ConsistencyGuid]),ConvertToBase64([mS-DS-ConsistencyGuid])),IIF(IsString([objectGUID]),CStr([objectGUID]),ConvertToBase64([objectGUID])))),IIF(IsPresent([mS-DS-ConsistencyGuid]),IIF(IsString([mS-DS-ConsistencyGuid]),CStr([mS-DS-ConsistencyGuid]),ConvertToBase64([mS-DS-ConsistencyGuid])),IIF(IsString([objectGUID]),CStr([objectGUID]),ConvertToBase64([objectGUID]))))

sa24

Click Add

If prompted with an Expression Warning, click Yes

Repeat for each additional Forest being synchronised

Creating a Rule to Write sourceAnchorBinary back into mS-DS-ConsistencyGuid

Now we have rules that correctly populate sourceAnchor and sourceAnchorBinary in the Metaverse, we need rules that write sourceAnchorBinary back into the on-premises mS-DS-ConsistencyGuid attribute -

Change the rule editor filter to show Outbound rules

Take note of the precedence of the last rule in the list

Click Add new rule

On the Description page, set the Name to Out to AD - mS-DS-ConsistencyGuid

On the Description page, set Connected System to the Forest you're currently configuring the rule for

On the Description page, set Connected System Object Type to user

On the Description page, set Metaverse Object Type to person

On the Description page, set the Precedence to a value higher than the precedence noted above (this will need to increase for each new rule created for each Forest)

sa25

Click Next three times

On the Transformation page, click Add transformation

In the new transformation set the FlowType to Direct, the Target Attribute to mS-DS-ConsistencyGuid, the Source to sourceAnchorBinary and the Merge Type to Update

Click Add

Repeat for each additional Forest being synchronised

Close the rules editor

Trigger a Full Sync

Open a PowerShell prompt and execute

Start-ADSyncSyncCycle -PolicyType Initial

You should now find that users are successfully synchronised to Azure Active Directory and that sourceAnchor is written back into msDS-SourceAnchor for on-premises objects

sa26

sa27

Conclusion

The rule changes configured here prefer mS-DS-ConsistencyGuidas the sourceAnchor source but use objectGuid when mS-DS-ConsistencyGuidis NULL. sourceAnchorBinary is written back to mS-DS-ConsistencyGuid in the on-premises object so that this attribute is always used after the initial sync, even after a migration of the user object between Forests.

Comments

  • Anonymous
    June 01, 2017
    Hi, do you have a script or solution for setting write (back) access on the msds-ConsistencyGuid attribute for the AD Connect service account if using Custom installation ?
    • Anonymous
      June 01, 2017
      Hi MikeI haven't encountered a need to do that. The rules I've described in this series have just worked and write-back has been successful. Can you expand on how your installation is custom and I'll have a think about it for you.
      • Anonymous
        June 02, 2017
        Hi Mark,We did a custom installation and used a domain user service account we created.We then give the service account "Replicating Directory Changes" and "eplicating Directory Changes all" permission in AD on the domain.Now when we sync we get an error permission error and the msds-consistencyguid is empty
        • Anonymous
          June 15, 2017
          Hi MikeSorry it took me a while to come back - been busy. I haven't looked at the scenario you're talking about but I have found the following reference which seems to discuss all the permissions relevant to AAD Connect. Hopefully this is helpful - https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-accounts-permissions
          • Anonymous
            June 16, 2017
            Mark,NP we are all busy :)I know the account needs write permission but do you have a script for this?$cmd = “dsacls ‘$HybridOU’ /I:S /G ‘”$accountName”:WP;msds-consistencyguid;user'”Invoke-Expression $cmd | Out-NullPerhaps dsacls command as above?
            • Anonymous
              June 20, 2017
              Hi MikeThat looks like it's probably correct but I wouldn't be sure without testing it. My suggestion would be to do just that.
  • Anonymous
    June 13, 2017
    Hi Mark, In a account/resource forest scenario (users exist in multiple directories) users are joined using their ObjectSID/msExchangeMasterAccountSID/msRTCSIP-OriginatorSID and mS-DS-ConsistencyGuid is not used as join anchor as described in this article. What is your opinion still adding mS-DS-ConsistencyGuid as a join attribute as a last step after the ObjectSID/msExchangeMasterAccountSID/msRTCSIP-OriginatorSID join rules? (not sure now how this is added in the most recent version of AAD Connect).
    • Anonymous
      June 15, 2017
      I have a colleague who tested with mS-DS-ConsistencyGuid as sourceAnchor while using the mail attribute to map into a resource Forest and I'm told that worked just fine. The choice of sourceAnchor is what uniquely defines the user object in AAD and its relationship to on-premises AD. The joining attribute you use to map into a resource Forest works with but is separate to the chosen sourceAnchor. In the end, I always tell people to test in a lab or a small set of users so that you can easily back out.
      • Anonymous
        October 07, 2017
        I have done ObjectSID/msExchangeMasterAccountSID/msRTCSIP-OriginatorSID with ms-ds-consistencyGuid in resource forest infra as we wanted to use different upn than email address. It’s working well. I have not created any of this rule.Do I need to create the write back rule or any other rule if I prepopulate ms-ds-consistencyGuid with objectGuid?
        • Anonymous
          October 07, 2017
          I you're using the latest version of AAD Connect, the setup wizard will use mS-DS-ConsistencyGuid by default and configure the write-back rules. You should open the sync rules editor and explore what you have. As I eluded to in the section about EmployeeID, any time an attribute is generated manually, it's probably not good. You want write-back rules and you don't want a process that requires your intervention any time you add a new user to the environment.