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.

Comments (4)

  1. turbomcp says:

    Thanks

  2. terry59 says:

    How does this work if an org wants to migrate to a new Forest? Users exist in Forest1 and they intend to migrate those users to a new Forest2 at a future date. Problem being that they need to provide Forest1 users with EOL ahead of the user migration to Forest2. Am I correct in thinking that you should deploy AADC to Forest2, then add Forest1 to AADC and scope AADC so that the initial sync of Forest1 users uses mS-DS-ConsistencyGuid for the immutableID. That way when ADMT migrates the users across to Forest2, AADC merges the users and EOL continues to work as before the move?

    1. Mark Renoden says:

      That's exactly correct. Note also that the latest version of AAD Connect uses mS-DS-ConsistencyGuid by default.

      1. terry59 says:

        Thanks Mark,
        Excellent article.

Skip to main content