Multi-forest integration

Larger organizations or distributed organizations have environments with multiple on-premises ADs. They're typically used in account/resource forests or provided through mergers and acquisitions. These rules need to be followed:

• Users have only one enabled account across all on-premises Active Directory Forests
• UserPrincipalName and Source anchor will be provided from the forest
• Users have only one mailbox
• Users that have a linked mailbox also have an account in a different forest
• There's no need to use Azure AD Connect on a domain-joined server

The following diagram shows the account/resource forest scenario:

Remember: multiple forests and multiple Azure AD Connect tools on one Azure AD aren't supported. The only exception is the usage of a staging server. A staging server can be configured for high-availability scenarios (active/passive). In this scenario, the staging server doesn’t export information to the target system.

If you have multiple forests, a single sync server and the users are represented in one directory and, you choose the option Users are represented only once across all directories, then each object in every forest is represented once in the Metaverse and aggregated in the target Azure AD tenant:

If you have numerous forests full of mesh with optional GALSync, you should use the User identities exist across multiple directories option.

If you use the mail attribute as matching criteria, the identity objects are joined with the mail attribute.This results in the following behavior—the user with a mailbox in one forest is joined with the contact in any other forest:

It's essential that objects are unique across AD forests. If objects are unique across every forest, you're in a good position. With object matching and joining, you can provide a good state when using cloud services. With the usage of joins, the precedence of synchronization rules also comes into play. If you join two objects based on an email address, and a specific attribute value where Object 1 isn't filled and Object 2 is populated, the value of the attribute (Object 2) will be used. But what if both objects have filled the attribute with different values? This is where precedence comes in.

The precedence will be set at the time of adding the forest to Azure AD Connect. So, if the forest of Object 1 was added before the forest of Object 2, the value of Object 1 will win the game. The preceding diagram shows this scenario.

Other objects are contacts you will find in such scenarios where a Global Address List (GAL) synchronization was implemented between two forests. Azure AD Connect provides the following default behaviors:

• If Azure AD contact finds a match of a contact and a user, a join will happen
• If there's no user object available, a contact object will be created
• If a subsequent user object is found with a match to a contact, a user object will be built in AAD
• If you have an account/resource forest scenario and you use the User identities exist across multiple directories option

If you use the matching criteria of ObjectSID and the msExchangeMasterAccountSID attribute, the expected results are that the users are disabled in this forest. Furthermore, the mailbox is linked to the account forest. The user will be presented uniquely in the Azure AD:

The preceding diagram also shows the Azure AD Connect behavior in a scenario where the AD object will be checked to determine whether it's a linked mailbox before it attempts to match msExchMasterAccountSID. This will be done with the recipientTypeDetails attribute. A value of 2 means that it's a linked mailbox. Keep in mind that disabled user accounts are also synchronized to Azure AD by default. Deactivated accounts are commonly used in exchange-resource forest deployments. The account forest holds the active user account and the resource forest holds the disabled user account. We will discuss rule precedence in Chapter 3, Exploring advanced synchronization concepts.