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


This blog post series is based upon and tested with AAD Connect, December 2016 release, version 1.1.380.0. Future AAD Connect releases may alter behaviour or expose new features that render this series redundant. 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 (0)

Skip to main content