Top tips for syncing on-premises Active Directory objects to multiple tenants

Hearing that an organization is migrating from their on-premises to one Office 365 tenant is a business case study we’re all familiar with now. And although this is becoming standard practice for businesses wanting to become more cost-effective, secure and flexible there are still implications to consider with this move. For example, in my line of work, I often come across situations where a local Active Directory object should be migrated to different Office 365 tenants and I’ll explain the multiple reasons why this occurs.

Firstly, a common reason for this is that the organization has subsidiaries who still want to share the on-premise service, but also want to be independent of the cloud services.

Another scenario I’ve come across is when an association wants to migrate an Active Directory object to multiple tenants. For example, if you think about a sports association, these often contain multiple sports federations and only some of these have the rights to use Microsoft non-profit subscriptions. In the case I’m referring to, it makes perfect sense to have a dedicated Office 365 tenant. However, this is from a cloud perspective, in the on-premise site, all the federations are still in the same Active Directory, in one forest, divided into different OU’s.

Our third reason is that a global organization has some local legal specifications. It could be that users and/or services from one destination cannot be used from the same side as another local destination (country)

These three examples all have one thing in common: they require you to synchronize one AD Forest into multiple tenants. As per Microsoft’s requirements, only one AD object can be synchronized to one tenant at a time. Which we can execute by using Organization Unit (OU) segregation in Azure AD Connect which I’ll delve deeper into in this article.

Active Directory

The first step to fixing this request is preparing the on-premise Active Directory. At this stage, you don’t need to focus on the forest functional level, the requirements for this task can be found here. Instead, your focus should be on having a detailed concept of which OU needs to be synced to which tenant as this is required for the configuration of the Azure AD connect later. As I mentioned previously, the reason for this is that we’re only supported to synchronize one AD object (user, group) into one tenant at a time, so we have to the objects to satisfy this requirement.

In the next picture, I’ve provided an example of how our Active Directory structure should look:

In this example, you can see a part of the Contoso on-premises Active Directory, and also two Destination OU’s “Switzerland” and Austria”. Each of these OUs contains sub-OUs with Users, Groups, etc. Here, we want to sync Users and Groups from the OU “Switzerland” to Office 365 Tenant 1 and Users and Groups from the OU “Austria” to Tenant 2.

Option one: Password Hash Synchronization (PHS) or Pass-through Authentication (PTA)

The supported solutions available to us are either Password Hash Synchronization (PHS) or Pass-through Authentication (PTA). To use either of these, you need to configure Azure AD Connect (AAD) in that way, so both tenants and the local Active Directory can be served from AAD servers. Later in this article, you’ll see how to configure the sync part of the local Active Directory OUs for each tenant. In the picture below, I’ve demonstrated how the design should look:

However, there is one very important point you must consider for this solution. If you use PHS or PTA, you’ll only be able to use SSO (seamless sign-on) for one of the two tenants. This means that you or the company must decide if Switzerland or Austria will be able to use SSO because whichever Destination OU SSO you don’t choose won’t be working. The reason behind this is the Kerberos Key exchange for the computer object AZUREADSSOACC can only be written for one tenant during the configuration of the SSO. However, if SSO is a must-have for both tenants, there is another solution to how this can be implemented.

Option two: PHS/PTA or Active Directory Federation Services (ADFS)

We discussed that there is an option to configure multiple Tenants with SSO on both sides. A supported solution for that request is to use it for one of the two sites PHS or PTA as described in the previous chapter, combined with SSO, and for the other Tenant an ADFS installation with or without PHS. This configuration structure will look like the picture below:

In the solution shown in the above diagram, Contoso has decided to configure the tenant for the Destination OU “Switzerland” with PHS or PTA with SSO and the Destination OU “Austria” with ADFS.  In this case, Contoso can use SSO for both Tenants. The solution with ADFS needs a higher financial investment because you’ll need to install at least two ADFS and two Web Application Proxy (WAP) servers, two times load balancing, and certificates.

Of course, there is also a solution with DNS load balancing, but in this case, I want to show you the most foolproof solution because I don’t recommend DNS load balancing.

So, what do I mean by the “chance” being higher when using third-party services? Well, if you look at the two main OU’s in this article, I’ve written about “Destination OU’s”, however they can vary based on your scenario. For example, you could have one tenant for administration, office and back office materials, and the second tenant for trading.

Trading departments are known for needing at recurring intervals a very high calculation power. Using a third-party cloud solution would enable you to fulfill that need and it makes sense for the trading tenant to be configured the SSO with ADFS.

Exchange Online and Teams Implications

The two options we’ve discussed, PHS/PTA or ADFS, are the preferred solutions. However, there is a crucial point that we need to contemplate here. If the association in question uses Exchange Online, it will only be available for one of the tenants. Microsoft currently doesn’t have a solution to create an Exchange Hybrid to multiple Office 365 tenants. It also looks like there is a similar case with Microsoft Teams at the time of writing, the main difference here is if the association is using different namespaces, then all tenants are able to use Microsoft Teams.

Azure AD Connect

When you start the configuration of AAD, one of the first points during the Wizard is to choose the sign-in method for your Users. As you can see, the first three options are the ones, that I described in this article:

To be more precise, if you choose PHS that means users can sign in to Microsoft cloud services, such as Office 365, using the same password as their on-premises network. The user’s passwords are synchronized to Azure AD as a password hash and authentication occurs in the cloud.

If you decide to use PTA, users can sign in to Microsoft’s cloud services, like Office 365, using the same password they use in their on-premises network. The user’s password is passed through to the on-premises Active Directory domain controller to be validated.

In this article, we’ve also discussed the third option using ADFS where users can sign in to Microsoft cloud services, such as Office 365, using the same password they use for their on-premises network. The users are redirected to their on-premises AD FS instance to sign in and authentication occurs on-premises. In this case, PHS can also be used in combination as a backup solution and for credential leakage detection in Azure AD Premium.

During the AAD configuration you will arrive at Domain and OU filtering, at this point you need to decide which OU’s need to be synced to which Tenant, which we described earlier in this article in the Active Directory section.

Note: If you’re using OU-based filtering with Azure AD Connect version before 1.1.524.0, new OUs added later are synchronized by default. If you don’t want new OUs to be synchronized, then you can configure it after the Wizard has completed the on-based filtering. For Azure AD Connect version 1.1.524.0 or later, you can indicate whether you want new OUs to be synchronized or not.

It’s also possible that some domains aren’t reachable due to firewall restrictions, consequently, these domains are unselected by default and have a warning.

Unreachable domains

If you see this warning, make sure that these domains are definitely unreachable and the warning is expected.

If you’re not so familiar with the configuration of AAD, I recommend you check out the Microsoft Technet article about the custom installation of Azure AD Connect.

For this configuration, you’ll need to have two Azure AD Connect instances, one for each tenant because, as previously mentioned, you can’t synchronize into two tenants with one Azure AD Connect server.

Conclusion

When faced with this challenge, the first and foremost action you must take is establishing how the future solution must look. Do all your sites need SSO? And, do one or multiple tenants in the future need a third-party cloud solution such as Salesforce etc. which requires authentication?

Once you’ve got a clear idea of how this should look, the next step is to create the design and prepare the Active Directory and Objects that have to be synced. With good preparation, this can be performed swiftly. Previously in this article, we discussed the considerations that need to be made because some of the services can’t be used in the Cloud, such as Exchange Online, or only with different namespaces, such as Teams. These restrictions can cause problems later and therefore must be accounted for early on. It’s similar to SharePoint and it’s permissions.

Even if the on-premise Active Directory is shared, the two tenants are completely independent. If the cloud service can’t be shared or federated, all services (e.g. Fileserver) must be located on-premise.