Forum Discussion
Azure AD Connect - One forest - Two tenants - Same OUs
Hi, Brad.
As you've noted, the topology is supported - albeit it with a growing list of caveats as noted here:
You do not need to separate the Active Directory objects (user or otherwise) into separate organisational units, but to reinforce one of the caveats from the article above, only a single instance of AAD Connect can be configured to write back to Active Directory meaning you must pay particular attention to ensure writeback is disabled when running AAD Connect's setup for the new per tenant instances of AAD Connect.
If I was going to call out just one additional caveat from the list in the article, it'd be the fourth last one:
It is not supported to add and verify the same custom domain name in more than one Microsoft Entra tenant, even if these tenants are in different Azure environments.
If the synchronised objects are going to use tenant-specific domain suffixes on their userPrincipalName, proxyAddresses, mail, sipAddress, etc. then this is not an issue (and my assumption this is the scenario you're facing). But if you're expecting they retain the same value across tenant, that's not going to be possible.
Cheers,
Lain
Thank you for the response, we definitely know there will be a lot of challenges with this. Here's the interesting part, the tenant has the users provisioned already through powershell directly into the tenant. We are being asked to bolt on a new Azure AD Connect, the immutable IDs match what is in the on premise AD. Would we need custom attribute mappings for upn, proxy address, mail, and sip if the same user object is going to be synchronized from on premise AD with the different domains to two tenants? We have been pushing to create two IDs since the two tenants are really separate entities. B2B can be used down the road for cross tenant collaboration.
You'd certainly need to apply attribute transformations to those name-based attributes to ensure they are per tenant-specific. i.e. You cannot have a user with the same userPrincipalName in two separate tenants.
If the immutableId is the same across all tenants and the joining criteria are the same, then all the Azure AD accounts across all tenants will join the underpinning Active Directory account, at which point any Azure attributes populated by the script will be updated with the on-premise values where applicable (be that with the direct value or transformed value).
Depending on how the attribute transformations are implemented within AAD Connect, and how closely that aligns to how the script behaved, it's definitely possible that some/all of these attributes could change value in each tenant.
Cheers,
Lain
