Forum Discussion
Azure AD Connect - One forest - Two tenants - Same OUs
Hi All,
We are looking to add a second Azure AD Connect to our environment to have users synchronized to a new tenant(second tenant different domain). According to Microsoft this is a supported approach, but is it also ok to have the same OUs as part of both syncs? We currently have situations where the same user object may belong to ContosoA and ContosoB or would the users that belong to each tenant need to be part of their own OUs and exclusive to each?
Thanks.
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
- Hello Brad13, I hope that you are doing well.
Using Azure AD Connect with one on-premises AD forest and synchronizing to two different Azure AD tenants is a supported scenario, as Microsoft allows a single forest to sync to multiple tenants. However, using the same Organizational Units (OUs) in both sync configurations can create conflicts if not managed carefully. When the same user object is synchronized to two tenants, it’s crucial to ensure that each Azure AD Connect instance is configured to manage the user objects uniquely for each tenant.
If the same OUs are used in both syncs without differentiation, you may encounter issues with object conflicts, especially if the same user is intended to be in both tenants. To avoid these conflicts, consider placing users that are intended to sync to each tenant in separate OUs or using attribute-based filtering to control which objects are synchronized to each tenant. This ensures that there is no overlap or duplicate synchronization, which can lead to unexpected behavior or errors in Azure AD.
In scenarios where the same users need to exist in both tenants, leveraging attribute-based filtering, custom synchronization rules, or creating separate OUs for each tenant would be a safer approach to ensure that each Azure AD Connect instance synchronizes the intended users without causing duplication or conflicts in attributes. This way, each tenant receives a distinct subset of users, and you maintain clear separation between the synchronization scopes.
If separation at the OU or attribute level is not feasible, you may need to evaluate whether the same users are required to be fully synchronized to both tenants or if a different strategy, such as selectively syncing only certain attributes to one of the tenants, would work better for your scenario.
Kind regards.Just to be clear, it is not supported to use a single AAD Connect instance to synchronise to multiple tenants. Each tenant requires the use of a separate AAD Connect instance - even if the source is a single Active Directory forest.
There's no issue with synchronising the same Active Directory object to multiple tenants. Segregation into per tenant organisational units is not required, though it's important to remember that only a single tenant can have write-back enabled for a given source Active Directory object.
You would only look to use organisational unit scoping or attribute filtering if write-back was enabled on more than one tenant, and even then, organisational unit scoping doesn't work in this scenario since it would restrict alignment of that source object to a single tenant, which is does not match the author's requirement for the object to concurrently exist in all tenants.
Attribute filtering could better handle dynamically associating write-back with a particular tenant based on the source object's attribute data - if such data even exists, however, complexity shoots through the roof as a result depending on which write-back scenarios are enabled within AAD Connect.
If there is one "main" tenant for all users/objects then it would be wiser to avoid organisational unit and attribute filtering altogether and simply enable write-back on that specific AAD Connect instance.
Another possibility is that write-back is not required at all, in which case there's zero need for scoping or filtering - or even this discussion, but where write-back wasn't particularly compelling maybe five years ago, there's more reasons/scenarios today where it would probably be enabled.
Consider having a single Active Directory forest and then separate tenants for production, test and development.
In this scenario, the production-aligned AAD Connect instance would have any write-back scenarios enabled, while the AAD Connect instances aligned to the test and development tenants would have all write-back scenarios disabled. No scoping or filtering is required.
Next, let's assume your production tenant default verified domain is contoso.com, with test being test.contoso.com and development being dev.contoso.com. If I were in Active Directory and all three Azure AD tenants, I would have the userPrincipalName of:
- Active Directory: lain.robertson[@]cotoso.com
- Azure AD prod tenant: lain.robertson[@].contoso.com
- Azure AD test tenant: lain.robertson[@]test.contoso.com
- Azure AD dev tenant: lain.robertson[@]dev.contoso.com
Note: I'm using [@] to prevent these forums from messing up the userPrincipalName values completely. You wouldn't see square brackets in a userPrincipalName.
What I could not have is lain.robertson[@]contoso.com across all three tenants, as the same verified domain name (contoso.com) cannot exist across multiple tenants.
This scenario is a fairly simple one. A more complicated one would be if the fictitious three tenants I used above were separate companies, with each being considered "production" and one or more write-back scenarios are enabled on each AAD Connect instance. In this case, you'd have to head straight to complex attribute filtering as organisational unit scoping is not going to deliver the result the author is seeking (of each on-premise user existing in all three tenants with dynamic write-back fluidly coming from a single tenant).
We have no information around the write-back scenarios from the author, so we're really just speculating here, but in general, avoid scoping and attribute filtering until it becomes impossible to do so (noting what I mentioned in the previous post about domain name translation, which you cannot avoid in the "exists in all tenants" scenario). Even then, be sure you understand the differences between what scoping versus attribute filtering will deliver as they are not the same thing even though they can be used to achieve the same outcome in some of the basic scenarios.
Cheers,
Lain
- LainRobertson josequintino
Thank you both for the very helpful information. Lain, in our scenario we would be synchronized to two production tenants contosoA.com and contosoB.com.
In this scenario if the user object has UPN, mail, proxyAddresses, sip Address that reflects one of the two wouldn't there be a need to do some custom attribute mapping in the on prem AD to ensure the respective domain values are correct for the tenant being synchronized to? Meaning UPN reflecting @contosoA.com but being synchronized to @contosoB.com would need a custom attribute mapping that contains the correct @contosoB.com address?
