Microsoft US Sovereign Cloud Myth Busters - A Global Address List (GAL) Can Span Multiple Tenants
Published Dec 12 2019 09:00 AM 14.5K Views
Microsoft

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. 

 

clipboard_image_4.png

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.

 

clipboard_image_5.png

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).

 

clipboard_image_6.png

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:


 

Blog Title

Aka Link

New! ND-ISAC MSCloud - Reference Identity Architectures for the US Defense Industrial Base

https://aka.ms/ND-ISAC/IdentityWP 

Microsoft CMMC Acceleration Update

https://aka.ms/CMMC/Acceleration

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

https://aka.ms/USSovereignCloud

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

https://aka.ms/MSGovCompliance

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

https://aka.ms/AA6frar

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

https://aka.ms/AA6vf3n

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

https://aka.ms/AA6xn69

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

https://aka.ms/CUISovereignty

Microsoft expands qualification of contractors for government cloud offerings

https://aka.ms/GovCloudEligibility 

 

11 Comments
Copper Contributor

Great explanation!  Definitely a worthwhile read!

 

In the effort to reduce / eliminate Spill.  There is a line of thought around providing a naming convention within the universal GAL to identity the correct person within the organization in regards to  ITAR/DFARS/etc....   i.e. Mary Smith (Gov) vs. Mary Smith, the counterpoint is that the organization does not want to call attention to their government workers / cleared personnel. 

 

Obfuscated identifiers could also be invoked;

  • Mary Smith (A) - Commercial Employee
  • Mary Smith (B) - US Citizen
  • Mary Smith (C) - OCONUS 

Next option could potentially be:

"Tool Tips" within the Outlook client triggered on GAL attributes

  • Tool Tip Display - This "Mary Smith" is outside the the Government Enclave are you certain this is your intent.
  • Tool Tip Display - Preventing sending to "Mary Smith" OCONUS
    • Create escalated exception process

Next option could potentially be:

Evoking "AIP Encryption" on the GCC High side environment for all personnel who are placing commercial aliases within email.  This can be accomplished by creating groups.  https://docs.microsoft.com/en-us/azure/information-protection/prepare

 

And not but least a combination of some or all of the previously mentioned options above.  Open to thoughts and comments - 

Copper Contributor

Nice job, Richard.  Just like we had discussed.

Microsoft

@Emilio Matt, I may leverage time over the holidays to write a follow-up on techniques for GALSync, such as how to set Azure AD Connect rules to calculate Display Names, MailTips, etc.  That would accommodate much of what you comment about.  At the end of the day, it will still be the IAM responsibility to stamp attributes such as US Person or US Citizen.

Iron Contributor

Has Microsoft developed a tool to convert that B2B guest user into a full Member user if the tenants are merged at a later date?

Microsoft

@Michael Gendreau, technically it is possible to flip the UserType attribute from Member<->Guest.  However, Microsoft support considers it unsupportable as engineering has not done the exhaustive testing to determine the impact across all of the workloads.  Between Azure and Office 365, it's dozens of services.  If you choose to use the technique, it's highly recommended that you thoroughly test all the user cases in your environment to make sure it doesn't do anything unexpected.  FYI, Azure AD is seriously considering taking up the effort.  You can provide feedback directly to engineering at https://stackoverflow.microsoft.com.

Microsoft

Excellent article very well explained - thanks for sharing.  

Copper Contributor

Great article, thanks @RichardWakeman!  If we're interested in pursuing the Active Directory Synchronization Service in our Azure tenant, how do we go about doing so?  I'm not seeing that as an option in the Application Catalogs, and web searches aren't turning up anything aside from the YouTube video you've linked to here...

Microsoft

@TristanRice Reach out to @Alan von Weltin for more information.

Microsoft

Thank you for your interest in the Active Directory Synchronization Service (ADSS) solution. ADSS is available from Microsoft Enterprise Services. Please contact your Microsoft representative for a datasheet on the service.

Copper Contributor

@RichardWakeman nice article. 
We created (together with Microsoft and Google) another solution for this problem. We do not sync contacts or B2B guests between GAL's, but we do create a GAL that spans multiple organizations.


We feel our solution could be interesting when the number of tenants starts to rise, or when you have a mix of smaller and bigger tenants.


Would love your opinion: https://www.federated.directory

 

 

Microsoft

Thank you for sharing!  I will check it out.

Co-Authors
Version history
Last update:
‎Nov 03 2023 01:35 PM
Updated by: