This article is the first 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 you cannot have a Global Address List (GAL) that shows up in multiple tenants.  You can in fact have a GAL that spans multiple tenants, to include a cross-sovereign cloud solution with a tenant in the Commercial cloud along with GCC High.  This is to help those organizations that must deploy into both a Commercial tenant and a GCC High tenant at the same time.  Many of those organizations have a requirement to light up a consolidated address book across both tenants.

Microsoft Hybrid Identity with Many Tenants

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.

AD DS on-premises may be setup in a hybrid configuration with multiple tenants in the cloud. 

Illustration 1: Microsoft Hybrid Identity with Two Tenants

In Illustration 1, the on-premises environment 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

The inherent challenge with this approach, is a single identity object (User, Contact or Group) should only synchronize to a single tenant at a time.  In other words, if a User (e.g. CommercialUser@contoso.com) synchronizes to the Commercial tenant, that user should be filtered from sync’ing to the GCC High tenant at the same time.  If the User is not sync’ing to the GCC High tenant, then it will not be visible in the GAL in GCC High.  The same applies in both directions.  If a User (e.g. GCCHighUser@contoso.us) synchronizes to the GCC High tenant, that user should be filtered from sync’ing to the Commercial tenant.  The result is each tenant will have a GAL consisting of only the Users in scope for the tenant.

The GALSync Solution

The first time I deployed a Global Address List Synchronization (GALSync) solution was back in 2003 with Microsoft Identity Integration Server (MIIS).  MIIS has evolved through several branding changes (e.g. ILM & FIM) and is now called Microsoft Identity Manager (MIM).

The scope of this article is not to answer how to build a GALSync solution.  MIM and partner offerings have GALSync solutions available that work with Microsoft 365.  Alternatively, I will focus on the concept behind a GALSync solution.

The GALSync concept is simple.  For every User that appears in one tenant, that same User will appear in other tenants as either an Exchange Mail-Enabled Contact or a B2B Guest User Account made visible in the GAL.  Let’s focus on contacts first, and then delve into Guest Users.

GALSync with Contacts

The traditional GALSync with Contacts is an on-premises solution.  Historically, it is leveraged to support GALSync with multiple on-premises Exchange Organizations.  The same concept applies when extending Exchange Server to the cloud with Exchange Online.

Illustration 2: On-Premises GALSync with Contacts

In Illustration 2, there are a few concepts to explain.  First, the Users, Contacts and Groups that are in scope for the tenant are represented in the Red color scheme.  For example, a Commercial User (e.g. CommercialUser@contoso.com) may synchronize directly from AD DS on-premises mapped to a User in the cloud (aka a Hybrid Identity enabled User).  This is the out-of-the-box behavior of AAD Connect.  However, the GCC High identity is filtered from sync’ing directly.  The GCC High User (e.g. GCCHighUser@contoso.us) does not synchronize to the Commercial tenant.  Alternatively, a GALSync solution will copy the GCC High User into another AD Forest and separate Exchange Organization as an Exchange Mail-Enabled Contact with the same Email address.  AAD Connect will in turn import those Contacts and synchronize them to the Commercial tenant represented in the Yellow color scheme.  The result is a GAL in the Commercial tenant counting the GCC High User transformed as a Contact.  This GALSync solution essentially converts the User in another tenant into a Contact in this tenant.

There is one limitation to Address Book visibility when using Contacts.  GALSync with Contacts will only appear in the Exchange GAL, but not elsewhere.  In other words, you can see the contacts in the Outlook address list, but not in the SharePoint people picker, nor in OneDrive for Business or in Teams.

GALSync with B2B Guest User Accounts

The GALSync solution with B2B Guest User Accounts is a cloud-based solution.  The end result is similar; this GALSync solution essentially converts the User in one tenant into a Contact in another tenant.  Except in this case the Contact is a B2B Guest User.  The benefit of using B2B Guest Users as opposed to Exchange Mail-Enabled Contacts is two-fold.  Like Contacts, the B2B Guest Users may be updated to appear in the Exchange Online GAL.  Only this time, the B2B Guest User is visible everywhere you want it to appear, including in Outlook, SharePoint Online, OneDrive for Business, Teams, etc.   In the Exchange world, a B2B Guest User is a Mail-Enabled User that is a security principal (aka a real user account).  Unlike Contacts, a B2B Guest User may take advantage of Azure Active Directory B2B and Microsoft 365 External Sharing scenarios.  Think of B2B as an ‘authorization’ scheme that enables users from outside the tenant to be entitled access to resources inside the tenant (e.g. Team group membership).

Illustration 3: On-Premises GALSync with B2B Guest User Accounts

Illustration 3 is a simplified view of the solution describing the tenant <-to-> tenant synchronization of Users to B2B Guest Users.  This solution assumes you still have AAD Connect in place, wired up individually with both tenants as depicted in Illustration 1.  In this illustration, a GALSync solution sits between two or more tenants in the cloud, reading from one tenant and writing to another.

B2B in the US Sovereign Cloud

As of the time of this writing, B2B is still roadmap in the US Sovereign Cloud, to include Microsoft 365 US Government (GCC High) and DoD.  There is a private preview for B2B between two tenants in the US Sovereign Cloud.  However, B2B does not currently function in a cross-sovereign cloud capacity.  When we do enable scenarios for B2B to work cross-sovereign, it will initially be made available from higher to low.  In other words, a User in GCC High will be able to access the low side environment in the Commercial cloud, but not the other way around.  There are still discussions on a bi-directional B2B solution.  As you can imagine, allowing Users from the low side access the higher side is quite the debate.  Microsoft will need to ensure any bi-directional B2B will not impact accreditation negatively.

You might ask why I describe the GALSync solution with B2B Guest User Accounts in the context of a cross-sovereign cloud solution?  This is to help those organizations that must deploy into both a Commercial tenant and a GCC High tenant at the same time.  Many of those organizations have a requirement to light up a consolidated address book across both tenants.  They also need a solution for the GCC High users to get access to applications and content in the Commercial tenant (e.g. the company intranet).  The GALSync solution with B2B Guest User Accounts will solve both requirements.  However, it is subject to the roadmap.  In the meantime, it’s not out of the question to do a tenant <-to-> tenant synchronization of Users to Contacts until B2B is ready.  When the time comes, simply swap out the Contacts for B2B Guest Users.

Appendix

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