AADConnect - Multi Forest Synchronisation Planning

  • Article

Hi,

I mentioned in a previous post that I would go into further detail on the Multi-Forest synchronisation scenarios. I'm a man of my word so here it is. :)

With consolidation, mergers and acquisitions common place in today's world, the Multi Forest capabilities of AADConnect are heavily utilised by customers. Customers really value these capabilities as it provides opportunities to quickly consolidate infrastructure into the Microsoft Cloud. This allows organisations to quickly have a level of collaboration that would be more difficult to achieve in the on-premises world. This post will detail some key considerations that you should review when planning for Multi Forest Synchronisation to Azure AD.

  1. The topology must be supported - There are a vast amount of topologies that "technically" you could deploy but only a set amount that actually are supported. See here for the supported AADConnect deployment scenarios.
  2. 1-1 relationship - There can only be a 1-1 relationship between an AADConnect server and an Azure AD instance (an additional AADConnect server in "staging mode" is the only exception) . An AADConnect server can have many Forests that it synchronises from but the target can only be a single Azure AD instance.
  3. ImmutableID - The ImmutableID (SourceAnchor) is an attribute that stores a value that will remain with the user for the lifetime of that object. This attribute is used to link the on-premises AD Object to the corresponding Azure AD Object (basically a key to show that the objects have a 1-1 relationship across the directories). One of the common attributes used is ObjectGUID (a value generated by the on-premises AD) and for scenarios where the user will remain in the same AD Forest for the lifetime of that object this is a good option. But for scenarios where the user has potential to move across AD Forests then ObjectGUID isn't a good choice. Why?, well as the name "ImmutableID" suggests the value cannot change. When you move a user from one AD Forest to another AD Forest the ObjectGUID will change, resulting in a broken link between the users AD object and AAD object. For this reason it is highly recommended that during your design phase you select a suitable ImmutableID. This is to ensure that even if users move across AD Forests then the ImmutableID will follow and the link will be maintained. Previous customers I have worked with have selected attributes such as msDS-ConsistencyGuid, Employee ID, HR generated ID's and alternative GUIDs. Key message is to really think about this before you do it…. More info here.
  4. AADConnect Connectivity - When planning for your Multi Forest deployment you must ensure that wherever the AADConnect server is deployed it must be able to resolve, connect and synchronise from all AD Forests in the topology. This means you need to ensure that the correct name resolution, network connectivity and firewall rules are configured to allow the AADConnect server to connect to DC's in all Forests of the topology.

Hope that’s useful and watch out for more posts coming soon!

MD

Comments

  • Anonymous
    July 05, 2017
    As of AAD Connect May 2017 release, version 1.1.524, the default sourceAnchor used by the setup wizard is mS-DS-ConsistencyGuid.