Choosing a sourceAnchor for Multi-Forest Sync with AAD Connect - Part 1, Introduction
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 3, An Aside on EmployeeID
Part 4, Using msDS-SourceAnchor
Part 5, Using mS-DS-ConsistencyGuid
Before We Begin
Today I'll be starting a small series of blog posts that discuss the issue of choosing a sourceAnchor for Multi-Forest sync with AAD Connect into Azure Active Directory. This is a topic that has been discussed by other bloggers but after looking at it myself, I don't think the whole story is out there.
I've heard folks touch on the reason it's important - for cases where users may be migrated between Active Directory Forests - but the steps to successfully migrate those users also seem hard to come by. My intent with this series is to explain the problem, explain the options you have for a solution, to step through those options and finally, to describe the steps you need to successfully migrate users from one Active Directory Forest to another without damaging their Azure Active Directory cloud identity.
In this post I'll assume you've seen the AAD Connect setup wizard before. If you haven't, read this - https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect
What is the sourceAnchor?
Referring to the document mentioned above - " The attribute sourceAnchor is an attribute that is immutable during the lifetime of a user object. It is the primary key linking the on-premises user with the user in Azure AD"
Where's the Problem?
If you step through the AAD Connect setup wizard in either Express mode or in Custom mode while leaving the sourceAnchor configured with the default, you'll be using the objectGuid -
On the surface, objectGuid seems reasonable because it's unique for each object in the Forest. In a Multi-Forest scenario, there's a very slim chance that two objects from different Forests may have the same objectGuid but the number of possible GUIDs is so high that it's really not a concern. The issue comes when user migrations occur. Consider this -
Here we have users from Forest1 and Forest2 synchronised to Azure Active Directory. Their sourceAnchor on-premises and in Azure Active Directory match.
Let's migrate a user -
Here, the Forest2 user, originally with a sourceAnchor value of srcAnc03 arrives in Forest1. The migration process actually creates a new user object (which comes with a new objectGuid) and then copies other attribute values across. The result is a user object that looks the same but with a different immutable value.
AAD Connect cannot sync the migrated user object with the one that already exists in Azure Active Directory due to the sourceAnchor difference. The best (or worst?) case scenario is that a new object will be created in Azure Active Directory assuming the migrated user account doesn't conflict on any important attributes such as the UPN (unlikely).
The Solution
It's probably pretty clear that we need to choose an attribute other than objectGuid that will persist across inter-Forest migrations.
A generally accepted practice is to populate the mS-DS-ConsistencyGuid attribute which is NULL by default. With the Windows Server 2016 schema, a new attribute called msDS-SourceAnchor has been added specifically for this purpose.
The implementation is not so simple as choosing either of them as you step through the AAD Connect setup wizard. There is extra work to do and because the aof each attribute is slightly different, the steps to using them are slightly different also.
In the posts that follow, I'll explain each choice and also the changes you'll need to make if you've already configured AAD Connect with objectGuid vs. a new deployment where you decide on either mS-DS-ConsistencyGuid or msDS-SourceAnchor from the get go.
Conclusion
objectGuid is a poor choice for the AAD Connect sourceAnchor especially in multi-Forest environments where user migrations are likely to occur.
ttribute syntax