ImmutableID – mS-DS-ConsistencyGuid – ADConnect

By rzomerman | | No Comments | Active Directory, Azure, Azure AD

The good thing about new software is that bugs and ‘features’ are removed.. the bad is that sometimes what ever you have blogged about makes either no sense, or even worse it only applies half to it from that point on.

So as AADSync was replaced by AD Connect, I got emails about the configuration of the mD-DS-ConsistencyGuid configuration in AD Connect not correctly working anymore. So, in order to relieve me from those email (you can still send them no worries) but more to make everyone aware of how this works in AD Connect (tested version 1.1.189.0); part two of the mS-DS-ConsistencyGuid as the immutable ID.

[update 21-Aug-2017: The latest version of Azure AD Connect have the functionality built-in to select the ImmutableID. There is no need to hack the rules manually anymore.. read more about it at: http://blog.azureinfra.com/2017/08/21/immutableid-ms-ds-consistencyguid-adconnect-final-part/]

Note: Jorge also posted a method of doing this using extensionAttributeX or the new (2016) msDS-SourceAnchor. Both attributes mentioned there are String valued attributes. In the scenarios I describe in my blogpost I’m solely using the ms-DS-ConsistencyGuid and ObjectGuid to ensure that we only use unique fields that are being filled by the absolute unique ObjectGUID attributes. My blogpost is especially handy for performing cross-forest migrations of user objects (that currently have AAD accounts) and to ensure that the AD-Connect engine is able to match the source forest user objectGUID to the migrated user’s ms-DS-ConsistencyGuid. In short, one identity having accounts in two AD forests, will be seen as a single entity in the sync engine. If you are performing a brand new implementation and you just want to use another base ImmutableID attribute, Jorge’s post is just as ok as mine.. (although I think mine is better anyway..;) ).

The big difference in approach is that his post uses the IF extensionAttribute15 is used, join based on that.. ELSE use objectID. My post uses solely the ms-ds-ConsistencyGuid. If that is not filled, we will fill it on the first synchronization attempt, but actual AAD export will happen only after the 2nd synchronization when ms-ds-ConsistencyGuid is filled. 

Starting

So the principles of the earlier blogpost described here still apply;

0: prepare the sync environment

1: add a new rule to import ms-ds-consistencyGuid and map it to the SourceAnchorBinary attribute in the MV

2a: change the default import rule to be disregarded if the ms-ds-consistencyGuid field in AD is present.

2b: change the default import rule to copy ms-ds-consistencyGuid value in the msdsconsistency field in the MV

3: change the other rules to incorporate ms-ds-consistencyGuid instead of object ID

4: create an outbound rule to update the AD ms-ds-ConsistencyGuid with the msdsConsistencyGuid (MV) value.

Within the new editor, creating, copying and editing rules has become a little bit easier as we shall see.. but first, lets create the attributes required and make sure that the AD connector (Management Agent) includes the ms-ds-consistencyGuid

0: Preparing the environment

Install AD connect onto a server and install/configure it with the Express Settings, however ensure that you disable the “start the synchronization process as soon as the configuration completes” checkbox

Now I could have retyped the whole thing, but go back to the old article, and follow the blue typed instructions under the Preparing the MetaVerse and Management Agents chapter.

And don’t worry, if you need to convert to a federated setup, you will still be able to do so later.

1: add rule to import ms-ds-consistencyGuid IF it exists and map it

  • Open the editor (C:\Program Files\Microsoft Azure AD Sync\UIShell\SyncRulesEditor.exe) and look for rule 100. That rule should still be available if you have run an express configuration.
  • Click the (100) rule which is named In from AD – User Join and select Edit.
  • a popup will show asking to disabling the rule and copying it into a new rule, click YES
  • A cloned rule will be showed, change the name to In from AD – User Join CGUID
  • Set the Precedence to 99
  • click next and for the scoping filter, add a new clause
  • ATTRIBUTE = mS-DS-consistencyGuid  /  OPERATOR=ISNOTNULL
  • click next
  • in the join rules, ensure that SOURCEATTRIBUTE=ms-DS-ConsistencyGuid    /   TARGET=sourceAnchorBinary
  • click next
  • in the Transformations page, ensure that the following is listed:
    • FLOWTYPE=Expression  / TARGETATTRIBUTE=cloudFiltered / SOURCE=<very long query, do not change>
    • FLOWTYPE=Direct   /  TARGETATTRIBUTE = sourceAnchorBinary/ SOURCE=mS-DS-consistencyGuid
    • FLOWTYPE=Direct   /  TARGETATTRIBUTE = sourceObjectGuid/ SOURCE=objectGUID

this completes rule 99

(sidenote, if you are getting an error about an attribute mapping with regards to cloudFiltered, click YES – you did not load the Exchange schema into AD and that’s causing the error)

2: edit existing rule 100

The original rule (In from AD – User Join) is now disabled (as we copied it to create rule 99), but it also requires the same changes as we made in the previous blogpost. So:

  • Click the (100) rule which is named In from AD – User Join and select Edit.
  • a popup will show asking to disabling the rule and copying it into a new rule, click NO
  • the rule is opened, on the main page, clear the checkbox next to the DISABLED option
  • click next
  • in the Scoping Filter window, click Add Clause and add
    • ATTRIBUTE = mS-DS-consistencyGuid  /  OPERATOR=ISNULL
  • click next
  • no changes required on the join rules
  • click next
  • on the transformations page add a transformation
    • FLOWTYPE=Direct   /  TARGETATTRIBUTE = msConsistencyGuid/ SOURCE=objectGUID / MERGE TYPE=UPDATE

3: change the other rules that use objectGuid

follow the same principle as in the original post, I found the following rules:

  • rule 102 “In from AD – User AccountEnabled”
  • rule 104 “In from AD – User Common”

change the expressions as per the original post under chapter: mS-DS-ConsistencyGuid as SourceAnchor (the blue marked text again)

4: create the outbound write ms-ds-consistencyGuid

Whenever a new account is created in AD, we need to ensure that ms-ds-consistencyGuid is filled in order for the user to be provisioned on Azure AD. For this we need to do the following.

  • In the rules editor window, on the left top, change DIRECTION from inbound to outbound
  • a new set of rules is being displayed, browse to one of the latest rules
  • click the Out to AD – User Join SOAInAD and click Edit
  • on the pop-up for copying the rule, click YES
  • rename the new rule to “Out to AD – User CGUID Write”
  • set a description if desired
  • set the Link Type to JOIN
  • set the precedence to 114
  • click next
  • on the scoping filter window remove all existing clauses and add one new one:
    • ATTRIBUTE msConsistencyGuid   /  OPERATOR=ISNOTNULL
  • click next
  • on the join rules, remove any existing rule and add one new one
    • SOURCEATTRIBUTE=sourceAnchorBinary  /  TARGETATTRIBUTE=objectGUID
  • click next
  • on the transformations page, remove any pre-existing transformations and add
    • FLOWTYPE=DIRECT  /  TARGETATTRIBUTE=mS-DS-ConsistencyGuid  /  SOURCE=msConsistencyGuid  /  MERGETYPE=Update
  • click save
    • (if an SQL error is provided (SQL Lock), go back to the first (description) page and set the precedence to 190. Save it. Reopen the rule and set it back to 114. You can also try other values as long as they are not in use.

 

  • IMPORTANT
  • The original rule that we copied the outbound rule from is still disabled, we need to enable it
  • click the Out to AD – User Join SOAInAD and click Edit
  • on the description page, clear the DISABLED flag and save the rule

That concludes it…

Tagged , , , ,