Choosing a sourceAnchor for Multi-Forest Sync with AAD Connect – Part 4, Using msDS-SourceAnchor

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.

Following on from my previous sourceAnchor posts, let's assume a new deployment with AAD Connect into an empty Azure Active Directory tenant.

I step through the AAD Connect setup wizard, adding the Forests from my lab (forest1.com and forest2.com), scoping sync to a single OU in each case (SyncOU) and choosing msDS-SourceAnchor as my sourceAnchor attribute -

I complete the wizard allowing initial sync to be triggered and wait … and wait … and nothing shows up in my Azure Active Directory tenant!

What's Going On?

If you go back to Part 2 of this series, I demonstrated that msDS-SourceAnchor starts life as a NULL value. What this means is that sourceAnchor in the AAD Connect Metaverse is not populated when the default sync rules are used. I can see this by running

"C:\Program Files\Microsoft Azure AD Sync\UIShell\miisclient.exe"

I then click on Metaverse Search and then the Search button which displays the objects imported from my Forests into the AAD Connect Metaverse -

If I double-click on one of these objects, I can see the attributes in the Metaverse that have been populated -

In this case, we cannot see sourceAnchor (I'll discuss sourceAnchorBinary in a later post)

It follows that AAD Connect can't create an object in Azure Active Directory. We'll need to modify the sync rules.

Editing the Sync Rules

When this opens, you'll notice that the rules are filtered by Inbound and that for each Forest, there are three rules that relate to Users -

The rules for each Forest are

In from AD - User Join

In from AD - User AccountEnabled

In from AD - User Common

Note: It is unsupported to edit the built-in rules. All you can do is copy them which disables the original. I'll copy the User Join rule and create a new rule that overrides the other two rules for just the sourceAnchor attribute

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 - msDS-SourceAnchor = 98

In from AD - msDS-SourceAnchor = 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 msDS-SourceAnchor and the Target Attribute to sourceAnchor

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

Click Next

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

Also understand that the conditions surrounding msExchRecipientTypeDetails are used to handle linked mailboxes in a Resource Forest and are implemented by the AAD Connect setup wizard (we want to keep them).

Creating a Rule to Write sourceAnchor back into msDS-SourceAnchor

Now we have rules that correctly populate sourceAnchor in the Metaverse, we need rules that write sourceAnchor back into the on-premises msDS-SourceAnchor 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 - msDS-SourceAnchor

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)

Click Next three times

On the Transformation page, click Add transformation

In the new transformation set the FlowType to Direct, the Target Attribute to msDS-SourceAnchor, the Source to sourceAnchor 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.

Conclusion

The rule changes configured here prefer msDS-SourceAnchor as the sourceAnchor source but use objectGuid when msDS-SourceAnchor is NULL. sourceAnchor is written back to msDS-SourceAnchor 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.

Great article! One remark: When using ADFS I would expect that solution it also impacts claim configuration on the relying party trust with AAD (if applicable). The claim rules also include the use of objectGUID as immutableID and should be changed when implementing this solution.