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

This article is the second 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 a domain should be able to span multiple tenants in Microsoft 365.  For example, many companies desire to have a single SMTP domain (e.g. Contoso.com) work for SMTP email addresses in multiple tenants.  I will explain why this is a very unwise idea if the two tenants are cross-sovereign cloud (e.g. Commercial and GCC High).

 

Domain Registrations in Microsoft 365

 

A discrete custom domain may only be registered to a single tenant in Microsoft 365.  The custom domain may be registered with DNS and added to Azure Active Directory (AAD), but only to a single directory.  For example, if you register Contoso.com in a Commercial tenant, you cannot register Contoso.com in a GCC High tenant at the same time.  However, you may register a sub-domain in a separate tenant.  For example, you may register Contoso.com in a Commercial tenant and @us.contoso.com in a GCC High tenant.  Or you may register a different domain suffix, such as Contoso.us.

 

For purposes of this article, my examples will use Contoso.com for a Commercial tenant and Contoso.us for a GCC High tenant.  Notice they both preserve the same Contoso branding?  Only the domain suffix changes based on the environment.

 

A custom domain is leveraged by Microsoft 365 in several ways:

 

• SMTP Domain: An SMTP domain is what appears in a user’s Email address.
• UserPrincipalName (UPN) Domain: A UPN Domain is the part after the @ in a user ID that you logon into Microsoft 365 with. The UPN is typically the same as the user’s SMTP Email address.
• SIP Domain: A SIP domain is what appears in a user’s Skype for Business and/or Teams account. This is used for instant messaging, presence and scheduling meetings.  The SIP address is typically the same as the user’s SMTP Email address.

 

Single Domain Routing

 

I often refer to a custom domain as synonymous to a DNS domain, as it must be publicly routable on the Internet.  In addition, a domain can only route to a single location.  In the case of email, you may only route SMTP Domain email to a single gateway with a DNS MX record registration.  You cannot redirect the route to multiple locations.  For example, if you route SMTP Domain email to a gateway in the United Kingdom, you cannot have DNS (the MX record) route to a gateway in the United States at the same time, at least not in a predictable fashion.  All email for the SMTP Domain will route to a single SMTP gateway (e.g. in the United Kingdom) and get re-routed (forwarded) by the gateway to its destination (e.g. in the United States).

The same concept applies to authentication with the UPN Domain.  If the UPN Domain routes all authentication to an Identity Provider (IDP) in a Commercial cloud, it cannot route authentication to an IDP in a Government cloud at the same time.  All authentication for the UPN Domain will route to a single IDP (e.g. in the Commercial cloud).

 

Authentication re-routing, or what’s called realm discovery, is not supported between Microsoft 365 Commercial and Microsoft 365 US Government (GCC High).

 

SIP Domain routing works pretty much the same way. The DNS records for the SIP Domain can only point to a single host at a time.  If the SIP Domain routes to a Title 22 CFR 126.1 deployment of Skype for Business Server, you sure as heck don’t want that route redirecting to your US Sovereign Cloud tenant in GCC High!

 

See a theme building here?
 

Why Microsoft Will Not Support a Single Domain Registered Cross-Sovereign Cloud

 

Most people believe that Microsoft will not support a custom domain to be registered in multiple tenants of Microsoft 365 because of a technical limitation.  There is some truth in that for multiple tenants in Commercial.  After all, complexity goes through the roof when attempting to implement the domain routing between multiple tenants when neither one is authoritative.  But that’s not at all the case in a cross-sovereign cloud topology.  When I refer to ‘cross-sovereign’, I mean between two tenants with one in Commercial and the other in GCC High.

 

Microsoft does not permit cross-sovereign domain registrations for compliance reasons.

 

We built the *US Sovereign Cloud with Azure Government, GCC High and DoD in a fully isolated environment that is both physically and logically separated.  All services in the US Sovereign Cloud are contained within an accreditation boundary supporting US Export Controls including the International Traffic in Arms Regulation (ITAR) and Export Administration Regulations (EAR).  US Export Controls require screened US persons and *data sovereignty in the Continental United States (CONUS).

 

*For more information on the US Sovereign Cloud, please refer to the Understanding Compliance Between Microsoft 365 Commercial, GCC, GCC-High and DoD Offerings

 

The isolation between these environments are in place to prevent data exfiltration from the US Sovereign Cloud.  This is a requirement enforced by regulations the US Sovereign Cloud must attest to.  Therefore, network firewalls are in place that prohibit single Domain Routing cross-sovereign cloud.

 

Take for example the Domain Routing for an SMTP Domain.  In the example above, SMTP Domain Email routing maps to an SMTP Gateway in the United Kingdom.  In the case of Microsoft 365, the SMTP Gateway is Exchange Online Protection (EOP) and would have to be hosted in the Commercial cloud where we have a region in the United Kingdom.  Microsoft will not allow redirection with the same SMTP Domain to GCC High in the US Sovereign Cloud.  Why?  Because Exchange Online has significant data processing of the SMTP Email that routes through it.  That includes message hygiene (e.g. virus scanning), data storage in a quarantine, and traversal of networks that are Outside the Continental United States (OCONUS).  Not to mention EOP in the Commercial cloud is administered with a follow-the-sun support model, including foreign nationals.  For the US Sovereign Cloud, that is forbidden!  To allow data processing OCONUS will place our accreditation at risk.

 

The same concept applies to the UPN Domain and the SIP Domain.

 

Microsoft cannot allow single domain routing cross-sovereign cloud as each scenario will result in data processing OCONUS.

 

Competing Jurisdictions

 

For the customers that struggle with this, the obvious solution is to simply consolidate into a single tenant in GCC High. Technically, you can entitle user accounts for anyone you see fit in GCC High.  That may include users that are foreign nationals and located OCONUS.  We do not block that.  At the end of the day, it’s your responsibility to be compliant while Microsoft holds up our end of the service agreements.  It’s a shared responsibility model for compliance.  If possible, reduce complexity by eliminating the cross-sovereign cloud solution and put all the commercial and government users into GCC High.  That way you hit the high bar for compliance across your entire user population (at least from a US jurisdictional point of view).

 

Competing Jurisdictions express the challenge I observe with the Defense Industrial Base (DIB) in particular.  A competing jurisdiction is where two collide with opposing requirements.  For example, a jurisdiction for Controlled Unclassified Information (CUI) categorized as Export Controlled (e.g. ITAR) must be sovereign to the United States.  Conversely, a jurisdiction for UK OFFICIAL data should have data residency in the United Kingdom.  You cannot have both ITAR and UK OFFICIAL jurisdictions apply to a single document or email at the same time as they oppose each other.

 

In the case where you must abide by multiple jurisdictions that compete, you may have no choice but to implement a cross-sovereign solution with a tenant in Commercial (e.g. in the UK) and a tenant in GCC High (e.g. in the US).  In addition, each jurisdiction must have its own autonomous single domain routing.

 

 Jurisdictions that require data residency/sovereignty must have separate domain routing.

 

Why a Customer Should Not Support a Single Domain Registered Cross-Sovereign Cloud

 

Now that you know cross-sovereign domain registrations are not a technical limitation, but a compliance feature of Microsoft 365 US Government (GCC High), you may be coming close to an epiphany.  For many of our multi-national customers, especially the aerospace and defense contractors of the world, they have many competing jurisdictions.  Often, they also have a single domain that spans the entire enterprise.  I learned early on not to put my customers on the defensive by asking how they believe they are compliant with each of those jurisdictions while using single domain routing.  When I did, they would look at each other and proclaim, “We don’t allow restricted data in Email”, or something along those lines.  However, we both know the majority of data spillage of CUI happens in Email.  Regardless, new US DoD regulations such as the Defense Federal Acquisition Regulation Supplement 252.204-7012 (DFARS) and the Cybersecurity Maturity Model Certification (CMMC) are changing the compliance posture on single domain routing.  You must keep data processing and data storage within the applicable jurisdiction.  In the case of the US DoD, you must ensure all single domain routing is within CONUS and managed on systems administered by screened US Persons.  For example, you should not route your email through a Commercial tenant that is destined for GCC High.  You will most likely be out of compliance. You might have all domain routing target GCC High and redirect to Commercial to stay compliant with US DoD jurisdictions, but then you risk non-compliance down-stream.  Or if it’s just Commercial users downstream, why not just put them into GCC High?

 

Keep the Single SMTP Domain; Create a New SMTP Domain Per Jurisdiction

 

Here is the compromise.  Remember I said you can re-route or forward SMTP Domain email?  This is a very popular technique to receive email.  For example, everyone can keep their Contoso.com email address to receive email.  If the SMTP Domain routing targets a Commercial tenant, you can setup forwarding to re-route email over to GCC High.  That way, people can keep advertising their Contoso.com email address to the world.  This may be used for email that is not subject to a jurisdiction.  At the same time, that same user will also send and receive email with their Contoso.us email address.  That way they can promote their Contoso.us email address to the mission owners over at the US DoD, and gleefully dish out Contoso.com in LinkedIn.

 

Appendix: AD Domain versus the DNS Domain

 

As a final note, we often have customers extremely confused on the difference between an Active Directory (AD) domain versus a DNS domain registered in Azure Active Directory (AAD).  Please don’t confuse the two.  An AD domain is a collection of identity objects within Windows Server Active Directory Domain Services (AD DS).  For example, you may have an AD Domain Controller for a domain that has a 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 attribute.  You can use any text values desired (e.g. Contoso.local), so long as it maps to an authentication scheme.

 

Appendix

 

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