Planning Azure AD Connect for multi-forest scenarios
more complex organizations it is common to have more than one Active Directory forest on-premises. For example, if an organization wants to implement account-resource forest topology, they will need to have two Active Directory forests. Another example for having two Active Directory forests is after there is a merger between an organization or acquisition.
Implementing directory synchronization between an on-premises environment with more than one Active Directory forest and an Azure AD tenant is a bit more complex than a scenario with only one Active Directory forest. However, Azure AD Connect supports connecting multiple forests to a single Azure AD tenant. A server that runs Azure AD Connect does not have to be joined to any domain locally, however, it must be able to access domain controllers in both forests.
In some cases, you can choose to place the Azure AD Connect server in a demilitarized zone (DMZ), especially if you do not have a direct network connection to all forests that you would like to include in the synchronization.
When planning for multi-forest scenarios, you need to consider the following:
- If you have two or more forests, one instance of Azure AD Connect must be used to synchronize all forests to Office 365.
- Only one instance of Azure AD Connect can be connected to an Office 365 tenant. You cannot connect multiple Azure AD Connect instances to one tenant.
- If you want to synchronize one or more forests to multiple Office 365 tenants, you need to use multiple Azure AD Connect instances, one for each tenant. However, you must consider whether user objects are represented once, or multiple times across the connected forests.
When you have more than one Active Directory forest locally, you must configure directory synchronization so that a single object in Azure AD represents each user. When you run the Azure AD Connect Setup Wizard with an option to customize the configuration, you can configure options for this on the Uniquely identifying your users page.
On this page, you can select between several options. The default option is that users are represented only once across all directories. This scenario assumes that each user has only one account in the forest where the user is authenticated during sign in. Additionally, if you implement Exchange Server, this scenario assumes that the user has only one mailbox in the forest that has the best data quality for attributes published to a GAL.
Another option is to select that user identities exist across multiple directories. In this case, you must choose how to perform user matching. You can do it by using a mail attribute or by using the ObjectSID and msExchangeMasterAccountSID attributes for example.