Choosing a sourceAnchor for Multi-Forest Sync with AAD Connect - Part 2, Lab Setup

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

Lab Setup

Before I get into the details, I want to cover to the lab setup I'll be using. It's really simple -

sa04

I scope AAD Connect to a single OU in each Active Directory Forest containing my test user -

sa05

and

sa06

Examining the objects, we see the values of objectGuid, mS-DS-ConsistencyGuid and msDS-SourceAnchor -

sa07

and

sa08

As you can see, mS-DS-ConsistencyGuid and msDS-SourceAnchor start life as NULL values.

The Metaverse

AAD Connect maintains its own database called the Metaverse. The Metaverse keeps a copy of the objects being synchronised. Connectors between the Metaverse and external databases are associated with rules that define how one attribute value maps to another. In this way, AAD Connect is able to extract information about a user object from an Active Directory database, populate the Metaverse copy with that information (potentially mapping one attribute into another) and then export that information to Azure Active Directory.

sa09

Depending on the attribute and the options selected when AAD Connect is configured, some values may flow from Azure Active Directory back to on-premises also.

The Plan

First we need to choose whether to use mS-DS-ConsistencyGuid or msDS-SourceAnchor. If you haven't installed the Windows Server 2016 schema, your only choice is to use ms-DS-ConsistencyGuid.

If you do have the Windows Server 2016 schema, use msDS-SourceAnchor. That's what it's there for and because the attribute syntax is a closer match to sourceAnchor in the Metaverse, it's slightly easier to set up.

Once that choice is made, the high-level logic for the attribute flow remains the same. For the rest of this post, I'll refer to either mS-DS-ConsistencyGuid or msDS-SourceAnchor as the immutableID.

Attribute flow pseudocode is simply -

 if (immutableID == NULL)
{
 populate Metaverse sourceAnchor using objectGuid
    write Metaverse sourceAnchor back into immutableID
}
else
{
    populate Metaverse sourceAnchor using immutableID
}

The implementation of these rules will be slightly different across a few different scenarios which will be covered in later posts.

Conclusion

An immutableID capable of surviving Forest to Forest object migrations may be configured using either mS-DS-ConsistencyGuid or msDS-SourceAnchor.