Mar 22, 2022
Understanding Azure AD Connect with multi-tenant scenarios– Planning Identity Synchronization
In more complex scenarios, you can synchronize objects from one (or more) on-premises forests to one (or more) Azure AD tenants, as shown in Figure 3.5:
Figure 3.5 – Synchronization to multiple Azure AD tenants
This is relatively new, from a supported topologies perspective. This is a potential solution if you need to support multiple tenants in your organization. Microsoft, however, recommends trying to consolidate to a single tenant where possible.
There are some important caveats with this design, primarily the following:
- You need to deploy an Azure AD Connect server to communicate with each tenant.
- While the same object can be in scope for multiple Azure AD Connect instances, Exchange hybrid writeback, device writeback, and group writeback are only supported by one tenant. If you configure those writeback features for more than one tenant and have the same object in scope for those Azure AD Connect servers, you will enter a race condition where the object will get continuously updated errantly.
- You can have Password Write-back enabled on multiple tenants for the same user object.
- Hybrid Azure AD Join and Seamless SSO can only be configured with one tenant.
- You cannot configure the same custom domain in more than one tenant.
As previously mentioned, Microsoft recommends trying to consolidate into a single tenant to get the best experience. And, regardless of the Azure AD Connect topologies selected, it is not supported to deploy more than one active Azure AD Connect server to a single tenant. If you need to connect multiple on-premises systems to a single Azure AD tenant, you can achieve that with a single Azure AD Connect server.
Identifying object source requirements
Since the purpose of Azure AD Connect is synchronizing user, group, contact, and device objects to Azure AD, you’ll need to make sure your objects meet the minimum requirements.
Microsoft has guidance surrounding preparing user objects for synchronization. Some attributes (specifically those that are used to identify the user throughout the system) must be unique throughout the organization. For example, you cannot have two users that have the same userPrincipalName value.
As you can see, very few attributes are required for an object to synchronize. Each attribute that is synchronized does have some core requirements around formatting, including length and allowed characters. Several attributes (such as mailNickname, userPrincipalName, mail, sAMAccountName, and proxyAddresses) must contain unique values – that is, no other object in the directory of any type can share those values.
More Details