Table of Contents
Part 2, Lab Setup
Lab Setup
Before I get into the details, I want to cover to the lab setup I’ll be using. It’s really simple –
I scope AAD Connect to a single OU in each Active Directory Forest containing my test user –
and
Examining the objects, we see the values of objectGuid, mS-DS-ConsistencyGuid and msDS-SourceAnchor –
and
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.
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.