The standard setting of Azure instance with ADFS is well known, standardized and implemented in the field.  We use an ADFS environment to create a federation to the Azure AD and decide which things we want to sync by Azure connect and which not. The permission handling for resource groups is managed by RBAC-Roles. The main roles are divided in owner, contributor and reader roles.

For more information about installing and configuring ADFS you can find HERE.

However, let us talk about managing multiple Azure AD instances with just one on-premises ADFS environment. If there are two on-premises domains which has implemented in two way trust between each other and each of it has their own tenant, it can be federated by a single high availability ADFS farm. These forests may or may not correspond to the same Azure AD. In this article I want to show you how this scenario works with Microsoft tools.

Note: Before we start you need to know, that device write back and automatic device join are not supported in this scenario. Azure AD cannot be used to configure federation in this scenario as Azure AD Connect can configure federation for domains in a single Azure AD!


How to go:

Before I start with the explanation of configuring the federating with multiple Azure AD, let us have a look on the topic. We can clearly see two way trust between Contoso and Fabrikam. We also see that there are two Azure AD tenants, one for each company and both companies are running one Azure AD Connect environment. Only the Contoso on-premise side has an ADFS environment. In the article I am writing about an Azure AD scenario, of course, this is also practicable for Office 365.

The on-premises Domain by has already configured a federation across ADFS to the Azure AD tenant On this side everything is configured as we know and I have shortly described in the beginning of this article. On the other side is a domain in Azure Active Directory.

The first step we have to do is to establish two-way trust between and This is needed for the ADFS environment of is able to authenticate users in the site. If you are not sure how you can create two way trust between two domains, you can find more information in the Microsoft guideline here.

When the first step of creating two-way trust is done, we need to continue with modification of the federation settings from If we have a look on the default issuer set for a single domain federated ADFS, it can look like this example: Azure Active Directory requires always a unique issuer, for each federated domain. In our case the same ADFS needs to federate two domains, so the issuer value needs to be modified in a way, that it is unique for each ADFS federates with the Azure Active Directory.

The best way to do that is if we start on the ADFS server an Azure AD PowerShell command prompt. Here we can perform the following steps:

First, we connect to the Azure Active Directory that contains the domain by using this command:


After we have made the login with an admin account, we need to update our federation settings that they are enabled for multiple domains. This we can do with this command:

Update-MsolFederatedDomain –DomainName –SupportMultipleDomain

So what happened now? – The issuer in the domain federation will now be changed to and an issuance claim rule will be added for the Azure AD Relying Party Trust to issue the correct issuer ID value on the UPN suffix.

As the last step, we need now to federate with the Contoso ADFS environment. For that we start with Azure AD a PowerShell session and perform the commands below… First, we need to connect to the Azure Active Directory of the domain. For that we can use the command again:


Now we need to convert the domain from managed to federate by using this command:

Convert-MsolDomainToFederated –DomainName –Verbose –SupportMultipleDomain

This command will now convert the domain to federate with the same ADFS. At this point we are done and all necessary settings are done. How you want to handle now your environment is up to you and your company policy (companies’ policies). If we have to verify the settings we just have done for both domains, we can run for each domain the following PowerShell command: