Microsoft 365 (M365) was released as a public hyperscale cloud collaboration suite of products in 2010, including hosted services such as Exchange Online, SharePoint Online and has evolved to include Teams, Planner and many more. From the beginning, the best collaboration experience for a single organization (legal entity) is within a single Microsoft Office 365 tenant and single underlying Entra ID (formerly Azure Active Directory) tenant where you have the highest level of trust across a user population. For most organizations, managing users in a single tenant provides them with a unified view of resources and single set of policies and controls that enable a consistent user experience. Microsoft recommends a single tenant model when possible, and many of the cloud services are designed for a single tenant. However, a single tenant is not always possible. Multi-tenant organizations (MTO) may span two or more M365 and Entra ID tenants – resulting in unique cross-tenant collaboration and management requirements. In addition, external collaboration extends beyond the tenant to partners and other parties that are not under organizational control.
This article focuses on the candidate reference architectures for identity to accommodate Multi-Tenant Organizations (MTO), and specifically those that have a deployment in the US Sovereign Cloud with Microsoft 365 US Government (GCC High) and Azure Government. It also addresses external collaboration in highly regulated environments, inclusive of organizations that are homed in either Commercial or in the US Sovereign Cloud.
As Office 365 has matured to become Microsoft 365 and with the introduction of Microsoft Azure, new and innovative means of collaboration have been introduced to accommodate multi-tenant organizations and highly regulated environments. However, not all the features have been available to organizations that deploy into the US Sovereign Cloud when introduced in 2016. The US Sovereign cloud was designed to protect US Government data from ending up in foreign adversary hands. Simple and ubiquitous sharing solutions were not acceptable to either the US Government or for Microsoft. As such, this cloud environment was designed to necessarily impede unauthorized collaboration and the unintended release of controlled data outside its boundaries. Technically speaking, the US Sovereign Cloud aligns with the higher watermark of compliance with the US Department of Defense (DoD) Cloud Computing Security Requirements Guide (SRG) Impact Level 5 (IL5). In addition, it was purpose-built to protect Controlled Unclassified Information (CUI) such as export-controlled data including the International Traffic in Arms Regulations (ITAR). This highly regulated and heavily restricted cloud environment has not been conducive to collaboration beyond its boundaries.
Once the Defense Industrial Base (DIB) began deploying into the US Sovereign Cloud, it became abundantly clear that controls on collaboration outside of the tenant boundary were too restrictive. Most DIB straddle commercial clouds alongside the government clouds. In other words, the DIB are multi-tenant organizations that have deployments in both commercial and in government. The DIB desperately needs a solution and reference architectures to collaborate “cross cloud” between cloud environments.
The need for cross cloud collaboration is not unique to the DIB. Once the DoD got settled into the US Sovereign Cloud, they realized new scenarios of collaboration existed. For example, in late 2017, Hurricane Harvey wreaked havoc across Texas. During the hurricane relief, the US Coast Guard wanted to collaborate with the FBI and local law enforcement. In addition, they were all working in concert with the American Red Cross. However, they could not collaborate effectively as each were in different cloud environments:
- US National Guard in the US Sovereign Cloud (DoD)
- FBI in the US Sovereign Cloud (GCC High)
- Local law enforcement in GCC
- American Red Cross in Commercial
- Organizations not hosted in the Microsoft cloud
The DoD has now validated use-cases for cross-cloud and gave Microsoft the green light to introduce new solutions to solve the dilemma. This was further amplified by the ultimate challenges imposed by the COVID pandemic where people were forced to work from home. Microsoft has been working with the DoD to enable cross-cloud collaboration with default security, such as with zero-trust architectures. In many use-cases, the collaboration is bi-directional in nature. Many had previously assumed collaboration from the US Sovereign Cloud would only be in one direction (browse down to Commercial) but proved to be wrong. For example, the US National Guard may host a meeting out of their US Sovereign Cloud (DoD) tenant and invite the FBI, local law enforcement and Red Cross in. Not only is this an example of cross-cloud, but it is also an example of four cloud collaboration into Teams hosted from the DoD tenant.
Before Microsoft could enable ad-hoc organic collaboration in cross-cloud scenarios, it was determined that a model for higher level of security is required for collaboration based on levels of trust. Thus, the Microsoft Collaboration Framework was born.
Levels of Trust
The Microsoft Collaboration Framework considers multiple levels of trust, extending from the highest level of trust achieved within a single Entra ID tenant, to the lowest level of trust afforded to ad-hoc collaboration that is organic by nature.
1: Standard Organization Collaboration
As mentioned above, the best collaboration experience for a single organization is within a single Entra ID tenant where you have the highest level of trust and control across a user population. For most organizations, managing users in a single tenant provides them with a unified view of resources and single set of policies and controls enabling a consistent user experience. Microsoft recommends a single tenant when possible, and many of the cloud services are designed for a single tenant. For example, there are services that do not yet support external identities. For these use-cases a single tenant is required to consume these services.
The vast majority of the millions of tenants deployed worldwide are standard organizations with a single Entra ID tenant for Microsoft 365 and Azure cloud services. With the 80/20 rule, when Microsoft solves for collaboration within a single tenant, it applies to 80% of the organizations on the planet. However, organizations that deploy into the US Sovereign Cloud, especially the DIB, fall into the more complicated 20%. This is why it has taken longer to solve for the additional complexity described below.
2: Complex Organization Collaboration
Complex organizations include multi-tenant deployments spanning two or more Entra ID tenants – resulting in unique cross-tenant collaboration and management requirements.
Complex organizations may have requirements that are complicated by:
- Collaboration across public, sovereign, and regional clouds
- Competing jurisdictions for compliance, such as data sovereignty in the U.S. versus Canada
- Political or organizational structures prohibiting consolidation to a single Entra ID tenant
- Mergers, acquisitions, and divestitures
- Partner and supply chain compliance
Complex organizations often have a higher level of trust as compared to what is offered by ad-hoc collaboration but may be a lower level of trust than a single tenant architecture. Many complex organizations would like to appear as one, even though they are deployed to many. Given a single legal entity manages the user populations in all tenants belonging to the complex organization, they may configure standing policies that honor the higher level of trust, including:
Unified Global Address List
- E-Mail domains shared between tenants
- Chat and calling with Teams
- Presence indicators
- Authenticated meeting join
- Calendar Free/Busy availability
- Ubiquitous document sharing
- Application access and single sign-on
- And more…
You may consider these features as having an established “trust” between two or more tenants. These trusts may be configured using Microsoft’s Cross Tenant Access Settings.
3: Extranet Collaboration
An extranet is a centralized repository of shared applications and content made available to authorized members of cross-organization work groups, including partners, subcontractors, vendors, suppliers, and potentially customers. This access is given to a subset of the content accessible from within an organization’s private network or intranet. An extranet is similar to a DMZ in that it provides access to services for authorized parties, without granting access to an organization's entire network.
In traditional implementations of an extranet, the organization owns and manages the identity for the external parties, including the credentials used to sign-in to the extranet. These “Sponsored IDs” have a higher level of trust as the host organization has full authority over how the credentials are used. Historically, this sponsored ID credential may have been stored in an extranet directory, such as within Active Directory Domain Services hosted within a DMZ. That is no longer a requirement. With new cloud-native capabilities including Entra ID external identities, it’s now possible to invite in external “Guest” user accounts that are not employees of the organization. With external identities, the organization no longer needs to manage the credentials. However, most organizations cannot simply pivot from traditional extranet to Entra ID external identities overnight. The two may co-exist in harmony for some period, or possibly in perpetuity.
Extranets may stay relevant into the future for many reasons. Most notably, supply chain compliance is pervasive across all sub-contractors for a specified US DoD contract. In some cases, these contracts and programs may include tens or hundreds of contractors in the supply chain. In the near-term, the expectation is that many of these contractors will take an extended period to get compliant, such as getting certified for the Cybersecurity Maturity Model Certification (CMMC). Thus, any non-compliant subcontractors are either eliminated from performance on a contract, or they must be invited into a compliant enclave or extranet to work with CUI. In the spirit of the extranet, the non-compliant subcontractor user may access relevant contract and program content without granting access to an organization's entire enterprise tenant.
Another related scenario for the extranet, is where you either lift up or shift down on the level of compliance. For example, if the enterprise tenant is certified for CMMC Level 2, but a contract requires Level 3, an enclave or extranet may be certified for Level 3 to lift up compliance. Or conversely, if the enterprise tenant is super restrictive such as having a tenant-wide US persons policy, an enclave or extranet may be designated for collaboration with non-US persons.
4: Trusted Partners Collaboration
Trusted partners include subcontractors, vendors, suppliers, and customers for which there is a long-term established relationship with. To build a higher level of trust with the partner, an agreement may be founded on the security and compliance posture of the partnership. For example, an agreement may include users and endpoints that are compliant with CMMC Level 2 to access CUI. Many companies may create a Memorandum of Understanding (MOU) to solidify an agreement for CMMC compliance to enable bi-directional sharing of content between the companies. Ultimately, a trusted partner will have a higher level of trust as compared to ad-hoc organic collaboration but may be a lower level of trust than between tenants owned by a single organization.
Trusted partners collaboration may include bi-directional sharing between tenants managed by multiple organizations. A primary difference between extranet as compared to trusted partners is ‘who’ owns and manages the credentials for external users. In the case of trusted partners, the partner will own the credentials.
5: Ad-hoc Organic Collaboration
Ad-hoc organic collaboration is the ability for an end-user to share a document, document library, Team, app, etc. with anyone that has an email address. The recipient of the sharing invitation may be hosted on the Microsoft cloud, or virtually anywhere else.
The first introduction of collaboration beyond the tenant boundary was ad-hoc and organic. For example, in the early days of SharePoint Online and OneDrive for Business Online, document sharing was enabled by default in an ad-hoc fashion. A user could organically generate a URL link to share a document on a one-on-one basis. The URL could be accessed from anywhere, with no controls or restrictions beyond having possession of the URL. If activated by the person sharing the document, it would require authentication with a One-Time Passcode (OTP) via E-Mail. While an effective tool, many highly regulated organizations would limit the use of ad-hoc sharing. Regardless, it remains a very popular feature in commercial tenants with its ease of use. This is especially compelling in comparison to other cloud products like Google and Box. Ah-hoc sharing is even relevant in US Sovereign Cloud tenants with a strong governance policy. For example, ad-hoc sharing may be enabled for document libraries to share general content while restricting CUI and highly sensitive information. This is due to the fact there is the lowest level of trust with ad-hoc organic collaboration.
Microsoft & National Defense ISAC Collaboration
The National Defense Information Sharing and Analysis Center (ND-ISAC) Cloud Security & Architecture and Microsoft Cloud Services Working Group “MSCloud” brought ND-ISAC members together with Microsoft subject matter experts to further elaborate common challenges, understand features, and provide updates on Microsoft’s Cloud Services roadmap. This Working Group regularly provides a forum to discuss best-practices and use cases among ND-ISAC member companies. It also provides a venue for the Microsoft team to update participants on their services roadmap, provide guidance on current technical challenges, and answer general how-to’s based on ND-ISAC member interest and feedback.
The article above is an excerpt from the white paper “Microsoft Reference Identity Architectures for the US Defense Industrial Base” resulting from of deep collaboration among the MSCloud Working Group. It provides the group’s consensus on common challenges coupled with guidance on potential ways to overcome those challenges.
Head over to https://ndisac.org to download a copy of the white paper today.
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 |
|
|
Microsoft CMMC Acceleration Update |
|
|
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 |
|
|
Microsoft US Sovereign Cloud Myth Busters - CUI Effectively Requires Data Sovereignty |
|
|
Microsoft expands qualification of contractors for government cloud offerings |