Azure AD Connect - One forest - Two tenants - Same OUs

josequintino Brad13 

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