Microsoft US Sovereign Cloud Myth Busters - Active Directory Does Not Require Restructuring

Published 01-07-2020 09:02 AM 4,182 Views

This article is the third of a series in the Microsoft Tech Community Public Sector Blog that explore myths of deploying Microsoft Cloud Services into the US Sovereign Cloud with Azure Government and Microsoft 365 US Government (GCC High). 


We will focus on the myth that Active Directory must be restructured to support a Hybrid Identity configuration with multiple tenants in the Microsoft Cloud.  The concern is that a single Active Directory on-premises cannot synchronize with more than one tenant of Azure Active Directory, or that compliance may be negatively impacted if you have identity synchronizing to tenants in both the Commercial environment and the US Sovereign Cloud at the same time. 


Microsoft Hybrid Identity with a Single Tenant 

Microsoft’s identity solutions span on-premises and cloud-based capabilities, creating a single user identity for authentication and authorization to all resources, regardless of location. This concept is known as Hybrid Identity.  The most common topology for Hybrid Identity includes the pairing of Windows Server Active Directory Domain Services (AD DS) on-premises with Azure Active Directory (AAD) in the cloud. 



 Illustration 1: Microsoft Hybrid Identity with a Single Tenant 


In Illustration 1Windows Server Active Directory represents AD DS on-premises.  This may be a single AD Forest with a single AD Domain, or multiple forests with multiple domains.  The on-premises AD DS topology is extremely flexible in a Hybrid Identity solution.  In the cloud, AAD provides the directory services for Microsoft Azure and Microsoft 365, to include Office 365 in this illustration.  AD DS replicates to AAD leveraging AAD Connect and may support multiple authentication schemes.  The ‘IDP’ here refers to the Federated Identity Provider (e.g. Active Directory Federation Services AD FS) for federated authentication.  Authentication schemes also include Password Hash Synchronization and Pass-Through Authentication.  In a Hybrid Identity solution, all authentication schemes support Single Sign-On (SSO) in one fashion or another. 


You will also observe ‘Hybrid Workloads’ in Illustration 1.  The on-premises servers may include any workloads setup in a hybrid configuration, such as Exchange ServerSharePoint Server and Skype for Business Server.  Hybrid enables scenarios including migrations, federated search, free/busy calendar sharing, etc. 


The key takeaway here is the default Microsoft Hybrid Identity solution is documented with a single tenant in the Microsoft cloud. 



Microsoft Hybrid Identity with Many Tenants 

AD DS on-premises may be setup in a hybrid configuration with multiple tenants in the cloud.  In fact, I deployed my very first customer into the Microsoft multi-tenant cloud with over 20 tenants back in 2007.  I’ve helped deploy several million seat customers with hundreds of tenants each paired back with a single on-premises AD Forest (per customer).  It most certainly can be done.  However, I frequently encounter customers that perform research online and read our default documentation to conclude they must bifurcate their on-premises directory infrastructure to support multiple tenants. 



 Illustration 2: Microsoft Hybrid Identity with Two Tenants (Bifurcated) 


In Illustration 2the on-premises environment is bifurcated per tenant.  There is an autonomous AD DS topology supporting commercial that is isolated from the infrastructure for the government side of the house.  There are some organizations where this is already the case.  Probably the most common scenario where bifurcation is natural (if not required) is with Non-US entities that have a subsidiary or business unit in the US to service the US Public Sector business.  I also find it a commonplace for System Integrators (SI’s) that have autonomous US Public Sector businesses.  However, this is technical not a requirement! 



 Illustration 3: Microsoft Hybrid Identity with Two Tenants (Consolidated) 


In Illustration 3, the on-premises environment is consolidated.  After all, many organizations have spent long, arduous years to consolidate the on-premises directory infrastructure!  They don’t want to turn back around and start divesting it apart.  In this illustration, there is one consolidated directory service for AD DS.  As with the single tenant topology, this may be a single AD Forest with a single AD Domain, or multiple forests with multiple domains.  In this two-tenant topology, the single on-premises AD DS is setup in a Hybrid Identity configuration with both tenants at the same time.  You will also observe there is a 1:1 mapping of AAD Connect per tenant.  Each tenant must have its own instance of AAD Connect, as a single AAD Connect will not support multiple tenants.

You may find this documented in Topologies for Azure AD Connect  


few key take-aways: 

  • To avoid additional complexitiesa single identity object (User, Contact or Group) should only synchronize to a single tenant at a time.  There are methods to dual-sync identity, but that is beyond the scope of this article and colors a bit outside the lines of supportability by the AAD Connect configuration wizard. 
  • UserPrincipalName (UPN), SMTP & SIP domains must match the domains registered in the tenant where the identity object is synchronized.  For example, if the UPN is that is registered in the Commercial tenant, that User will only sync correctly to the Commercial tenant.  And vice-versa, if the UPN is that is registered in the Government tenant, that User will only sync correctly to the Government tenant. 
  • You may deploy a single IDP (e.g. AD FS) for use with multiple tenants, given the UPN domains are unique per tenant.  However, I’ve found many in the Defense Industrial Base (DIB) prefer separate IDP’s as they are often managed with a separate set of policies (e.g. Hard-Token MFA versus Integrated Windows Authentication). 


I am keeping this article 30,000 feet.  There are many considerations to this topology, especially if you find yourself having to migrate users from one tenant to another.  That is beyond the scope of this article.  Please feel free to comment and ask questions. 



Appendix: AD Domain versus the DNS Domain 

As a final note, we often have customers extremely confused on the difference between an AD domain versus a DNS domain registered in AAD.  Please don’t confuse the two.  An AD domain is a collection of identity objects within AD DS.  For example, you may have an AD Domain Controller for a domain that has a hierarchical directory of all the users in an organization.  Conversely, a DNS domain is publicly registered for use in an SMTP email address, a SIP address or a UPN user ID.  It’s common the Fully Qualified Domain Name (FQDN) for an AD Domain may match a DNS name (e.g., but it’s not technically a requirement.  For example, many older deployments of AD DS use non-routable FQDN’s (e.g. @contoso.local).  You can have an AD Domain FQDN be but assign a UPN for a user that has a DNS domain suffix.  At the end of the day, the UPN attribute in AD is simply a text value.  You can use whatever values you want (e.g. @contoso.local), so long as it maps to an authentication scheme.  I believe I’ll write another article on that topic alone. 




Please follow me here and on LinkedIn. Here are my additional blog articles:


Blog Title

Aka Link

Accelerating CMMC compliance for Microsoft cloud (in depth review)

Updated! Microsoft CMMC Acceleration Program Update – January 2021

History of Microsoft Cloud Service Offerings leading to the US Sovereign Cloud for Government

Gold Standard! Understanding Compliance Between Microsoft 365 Commercial, GCC, GCC-High and DoD Offerings

The Microsoft 365 Government (GCC High) Conundrum - DIB Data Enclave vs Going All In

Microsoft US Sovereign Cloud Myth Busters - A Global Address List (GAL) Can Span Multiple Tenants

Microsoft US Sovereign Cloud Myth Busters - A Single Domain Should Not Span Multiple Tenants

Microsoft US Sovereign Cloud Myth Busters - Active Directory Does Not Require Restructuring (This One)

Microsoft US Sovereign Cloud Myth Busters - CUI Effectively Requires Data Sovereignty

New! Microsoft expands qualification of contractors for government cloud offerings 


Senior Member
Thanks for a very good explanation. Would Illustration 3 still work if DNS Domain, AD Domain and Forest are all the same onpremise?

Howdy @avbhaskar!  Yes, even a single forest/domain with a single DNS, FQDN, etc. work with this architecture.  As called out in the appendix, the domain married to a tenant in Azure Active Directory is associated with the assigned userPrincipalName (UPN) for a specific user or group.  Assuming the UPN matches your DNS domain, FQDN, etc. today, that will only map to a single tenant.  To enable users/groups to map to a different tenant, you will need to change the UPN domain to match the target tenant's registered custom domain(s).

Occasional Visitor

Can you run the hybrid configuration wizard twice? Once for Commercial, Once for GCC High?

Occasional Visitor

How do you enable the multi hybrid from the single exchange organization? I've reviewed the logs from a  GCC High Hybrid deployment and they are way different than a commercial tenant.  And I can't reverse engineer the commands to run on our GCC High tenant.


Howdy @JustinRobbins!


You can only run the Exchange Hybrid Configuration Wizard against 1 tenant.  If the wizard is run against a 2nd tenant, it will overwrite the configuration of the 1st.  It will require a manual configuration on the 2nd tenant, and any additional tenants.  I agree it will be difficult to parse out the logs to determine the differences.  Most folks will copy the resulting configuration.  For example, you can reverse engineer the send/recieve connectors, remote domains, organizational relationships, etc and manually create them for the additional tenants.  This configuration is visible in the Exchange Admin Center GUI.

Version history
Last update:
‎Jan 08 2021 02:05 PM
Updated by: