This post has been republished via RSS; it originally appeared at: New blog articles in Microsoft Tech Community.
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 1, Windows 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 Server, SharePoint 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 2, the 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
A few key take-aways:
- To avoid additional complexities, a 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 @contoso.com that is registered in the Commercial tenant, that User will only sync correctly to the Commercial tenant. And vice-versa, if the UPN is @contoso.us 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. @contoso.com), 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 @contoso.com but assign a UPN for a user that has a @contoso.us 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.