Exploring the Value of Microsoft 365 Multi-Tenant Organizations

Directory Synchronization Needs Support in Apps to Expose Advantages

Update: April 25, 2024, Microsoft announced the general availability for multi-tenant organizations.

As expected, the announcement of the Microsoft 365 multi-tenant organization (MTO) attracted a lot of attention. Some folks wondered if the MTO marks the end of tenant-to-tenant migrations (nope!). Others struggled to understand how the different Microsoft 365 apps cope with the appearance of a bunch of new user objects synchronized into a tenant directory, and the inevitable questions arose about licensing (always a subject that raises passions).

In this article, I answer some of the most common questions I’ve received and explain why multi-tenant organizations need app support before the user objects created through cross-tenant synchronization are useful.

Multi-Tenant Organization Basics

First, let’s set the stage by reviewing the essentials of a multi-tenant organization:

• A multi-tenant organization can span up to five tenants. One is the owner (master or primary). The other tenants are members.
• Within a multi-tenant organization, tenants synchronize selected user objects (up to 100,000) to the other tenants. A tenant has separate synchronization configurations for each of the other tenants in the multi-tenant organization.
• Synchronization only processes user objects. Anything else is ignored (Microsoft 365 groups, security groups, distribution lists, mail contacts, and so on).
• The Entra ID cross-tenant synchronization mechanism processes updates between tenants.
• Updates applied to user accounts in their home tenants synchronize to the other tenants and overwrite any changes made in those tenants. For instance, if you update the display name for a user account synchronized from another tenant and that tenant changes the source account, a subsequent synchronization cycle overwrites the display name.

In a nutshell, a multi-tenant organization is a Microsoft 365 construct built on Entra ID cross-tenant synchronization capabilities to establish a directory of known user objects.

Multi-Tenant Organization Configurations

You can control some aspects of synchronization using the configuration created by the multi-tenant organization for a tenant. These configurations are accessible in the External Identities section of the Entra ID admin center under cross-tenant synchronization. For instance, you can change how often synchronization happens or what attributes are processed by editing the configuration for a target tenant. Figure 1 shows the set of default attributes processed by MTO synchronization.

In the same place, you’ll find the provisioning logs that report the success or failure of replicating changes to target tenants. For example, Figure 2 shows details of properties modified for a user object during a synchronization cycle.

User Objects Synchronized within Multi-Tenant Organizations

The result of synchronization from a host tenant to another tenant in an MTO are user accounts that:

• Have similar user principal names to guest accounts (like Ben.James_Office365itpros.com#EXT#@o365maestro.onmicrosoft.com) but are member accounts.
• Are visible to address lists (unlike the default setting for guest accounts) and therefore appear in the Outlook GAL. The objects have a valid email address (in their host tenant) and are addressable for email. Figure 3 shows the properties of the user account as viewed through the Outlook GAL. It’s the same account as seen in the provisioning log details shown in Figure 2.
• MTO accounts are enabled and have a system-generated password and alternative mail address.

MTO accounts are not locked against changes. You can update account properties if you wish, but should avoid the properties involved in synchronization. For instance, a host tenant can update the photo for an MTO account (which is what I did for the account shown in Figure 3). You can also assign licenses to the synchronized user objects and change their passwords. User photos, licenses, and passwords are not included in synchronization attribute mapping, so they persist through synchronization cycles originating from the home tenant.

If you update an account password, you can sign into a synchronized user account and use it as normal. Team owners can add MTO accounts to team memberships and if you then sign in with a MTO account that has a license to use Teams, you can use the account to chat, participate in channel conversations, and work on shared documents in the team’s document library. However, the account’s calendar is inaccessible because Exchange Online tries to connect to the calendar in the mailbox of the home tenant. Viva Engage and Planner don’t work either. In addition, signing into Teams using the source account for the MTO account won’t allow that account to interact with the team because that account is not in the membership. If you want someone from another organization to participate in a team, add them as a guest account.

I noticed that the Teams Aad Sync process adds MTO accounts synchronized from other tenants to any org-wide teams that exist in the organization. Org-wide teams are supported only in organizations with less than 10,000 accounts. Adding MTO accounts is an example of a bug that I’m sure Microsoft will fix before multi-tenant organizations achieve general availability.

It All Comes Down to Apps

All of this goes to prove that account synchronization between tenants is eminently possible but Microsoft 365 apps need to understand how to cope with the synchronized accounts. The new Teams 2.1 client is the first to make the move. In an August 28 blog post, Microsoft explains that the Teams 2.1 client can detect when an external account belongs to a common multi-tenant organization (by looking up the local directory to see if a member account exists for the external user). When this happens, Teams enables richer collaboration (like file sharing) because, by definition, the external account exists due to mutual trust between two tenants.

Compare the situation to regular guest accounts and external federated chat. Unless prevented by an Entra ID B2B collaboration policy, group owners can invite anyone to become a guest member. That guest member account persists in the host organization unless it is removed. The new sponsor feature for external accounts might help here, but most guest account clean-up remains an intensely manual affair, like finding guest accounts with unredeemed invitations or reporting or removing old guest accounts. The point is that apart from the trust placed in a guest account by the person who created it, an average user cannot take the presence of a guest account in their tenant as any indication of its trustworthiness.

External federated chat is even less trustworthy. The fact that an external person can use Teams doesn’t tell you anything about who they are or what harm they could do. Some security researchers have illustrated how it’s possible to send malware via federated chat, which is why I recommend that organizations consider restricting external access to known domains. The process of managing the set of permitted domains can be painful, even using PowerShell scripts, but it’s better than leaving a potential route into Teams for attackers to explore.

Membership of a multi-tenant organization implies trust between the linked tenants. They know about each other, they have administrative connections (needed to manage synchronization), they agree to synchronize account information to form a common list of user accounts, and the logic driving the trust is to enable better collaboration between the tenants in a joint organization. None of this exists for guest accounts or external federated access, and that’s why accounts within multi-tenant organizations are deemed to be more trustworthy.

Apps are the limiting factor. It’s good to have Teams leading the way but now the other mainline apps need to figure out how they can leverage MTO accounts. For instance, Exchange Online could drop the external tagging of email from MTO accounts. Microsoft Information Protection might add a special access permission for MTO accounts so that these accounts receive the same rights as tenant members to content protected by sensitivity labels. Data Loss Prevention (DLP) policies might change their definition of when content is shared outside the tenant to consider MTO accounts to be internal rather than external. Information barriers and communication compliance policies might also treat MTO accounts differently, and so on.

Microsoft 365 is a big place with a ton of application functionality to investigate and figure out where MTO accounts still need to be regarded as external and where they can be better trusted. I’m sure that this work is ongoing across the board and will appear over time.

The Question of Tenant-to-Tenant Migrations

Some have asked if multi-tenant organizations remove the need for tenant-to-tenant (T2T) migrations. I don’t think so. By their very nature, T2T projects:

• Span much more than user accounts in directory synchronization – Microsoft 365 groups, security groups, distribution lists, contacts (and maybe public folders), and so on are included in the information exchanged between tenants.
• Can involve more than five tenants.
• Move user accounts and other objects from one tenant to another, including personal data like mailboxes, Teams chats, and OneDrive for Business accounts.
• Move data in shared repositories like SharePoint Online sites and Teams from one tenant to another.
• Remove protection (sensitivity labels) from transferred data.
• Can transfer other intellectual property like scripts, programs, and automation runbooks.

In short, the current multi-tenant organization preview takes care of limited directory synchronization for a small set of tenants. It doesn’t attempt to take on the complexity often inherent in a T2T project. I think multi-tenant organizations offer real value, especially as Microsoft builds out app features that take advantage of account trustworthiness, but it’s more of a directory synchronization play (like the classic GALsync tool) rather than a replacement for T2T migration, or even a short-cut to T2T migration.

Multi-tenant organizations are in preview. I expect that Microsoft will add other capabilities over time, perhaps introducing the ability to synchronize more than user accounts. However, in saying this, the magic of the multi-tenant organization is the ability for apps to recognize external users as being more trustworthy than other people from outside a tenant, so maybe that’s where Microsoft will focus their efforts (to develop app features as discussed above) instead of expanding the breadth of synchronization.