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.
On Demand Migration
Migrate all your workloads and Active Directory with one comprehensive Microsoft 365 tenant-to-tenant migration solution.
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.
![Attributes processed by a cross-tenant synchronization configuration](https://s40823.pcdn.co/wp-content/uploads/2023/09/MTO-Synchronization-Settings-1024x792.jpg)
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.
![Provisioning log details for a synchronized user account](https://s40823.pcdn.co/wp-content/uploads/2023/09/MTO-Synchronization-Logs-1024x441.jpg)
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.
![Properties of a synchronized user account viewed through the Outlook GAL](https://s40823.pcdn.co/wp-content/uploads/2023/09/MTO-Synchronization-User-1024x604.jpg)
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.
On Demand Migration
Migrate all your workloads and Active Directory with one comprehensive Microsoft 365 tenant-to-tenant migration solution.
Is there a way this can help in getting shared mailboxes accessed by users from another tenancy as federated users ?
I have been trying but no luck yet and there is nothing in terms of any documentation from MSFT.
I thought that after users synched as members in another tenancy, they should be able to see the shared mailboxes but I have tested it and its not working.
How can we achieve this ?
The Real Person!
The Real Person!
Accounts synchronized from another tenant in an MTO are not used to access resources unless the application includes code to allows this to happen. Exchange expects shared mailboxes to be accessed using accounts that people sign into rather than representations of accounts from another tenant. If you want this kind of access, you should consider Outlook groups with guest accounts.
Hi,
Does anyone know if you MTO setup and you add a group to the sync will it support nested groups?
The Real Person!
The Real Person!
What type of nested groups? Have you tested with certain types?
Hi There Tony! Do you know if the calendar functionality, especially trying to add/show a calendar from a host tenant account, is not working properly/limited on a multi-tenant setup?
The Real Person!
The Real Person!
I don’t, but maybe you need to be more specific?
Just a quick clarification on this statement:
“Within a multi-tenant organization, tenants synchronize selected user objects (up to 100,000) to the other tenants.”
It’s not the limit of user objects that can be selected to synchronize, it’s the total number of user objects in a tenant to be used in a MTO. The limit is applied when creating a MTO or adding a tenant to a MTO.
So if you’re planning to sync 500 users out of your 300k users in the tenant, you will not be able to create the MTO or add your tenant to a MTO until Microsoft makes a change in their back-end. Hope this is helpful for others who are in the process to plan for MTO.
Tony, do you have knowledge of the MS roadmap with regard to MTO in terms of time and features?
Specifically, a rough idea of when, what and how the features and functionality for Outlook, Teams, OneDrive, Sharepoint etc will be rolled out within a proper release?
The Real Person!
The Real Person!
Nope. Funnily enough, Microsoft doesn’t share that information with me. And if they did, my NDA would stop me saying anything.
I noticed that when you search for a user from the source tenant in OWA in the destination tenant, the email displays correctly.
However, if the user has previously accessed the destination tenant, such as accessing a SharePoint site, the email changes to the #EXT# email address. As a result, it becomes impossible to send an email to this user.
If you lookup the user object in Entra, its shows the email field correctly.
Did you run in to this issue also?
Any idea if you can link a GCC or GCCH tenant to a Commercial Tenant?
A little more narrative on MTO, Group sync in Cross Tenant Sync is on the Roadmap.
When discussing Business to Business (B2B) and MTO, I always recommend looking at each workstream (Outlook, Teams, SharePoint, OneDrive, Power Apps, Power BI, 1st party Apps, 3rd party apps) independently as they all can have a slightly different End User experience when evaluating B2B or Tenant to Tenant (T2T) migrations.
Microsoft’s Recommendation is always a Single Tenant “whenever possible” for many reasons. MTO can make the B2B experience less painful, but all the Pros and Cons should be evaluated for the near term and long term. MTO is also for customers that have what I call a higher level of “business trust” because you are allowing the other company to provision Guest Accounts in your tenant. This isn’t really targeted for partners/vendors as much as multiple tenants in the same company.
Regarding the accessibility of the synced user calendar – Organization Sharing worked for me in the single tenant-to-tenant synchronization.
It adds some more work to be done (maybe at some point it will be done automatically), but it’s possible. I haven’t cheked Teams, but calendar was properly visible for synchronized user in Outlook’s scheduling assistant. As long as the background mechanism is the same, it should work in Teams as well.
The Real Person!
The Real Person!
Calendar synchronization will work between regular accounts. It’s using the special form of member accounts created in the MTO is where I think work is needed. For instance, if I want to share a calendar with another account in the MTO, Outlook (Teams) should understand that the other account is trustworthy and therefore automatically share whatever data is available to other tenant users. That kind of thing…
Tony, thanks for the answer.
So you mean it should work without setting the Org Sharing between source and target tenant?
It wasn’t working for me…
I wonder if checking the user presence in Teams is possible. It wasn’t working for me as well.
When sharing the file or inviting to Team, a mail was sent in the background, to the email address related to source tenant account. Then source user accessed file/team using source tenant account and all was ok.
But for the native target tenant user, finding the synced target account (@o365maestro.onmicrosoft.com in you case) isn’t showing the current team status of the source tenant account (@Office365itpros.com in your case). Those are different accounts, but showing status or being able to chat right away is sth I can imagine needed. Or it is possible and I’m missing sth ?
The Real Person!
The Real Person!
No, I mean that seamless calendar synchronization is an achievable goal within an MTO if Microsoft treats MTO accounts as equivalent to tenant member accounts…
As to Teams, you need the latest version of the Teams 2.1 client, and the range of actions that take advantage of the MTO is still limited. This is a preview feature and we’re still discovering where the gaps are. Teams 2.1 is also preview and is updated regularly. In other words, we are on somewhat shaky grounds when testing anything today. I don’t see anything about presence in the August 28 Microsoft blog that describes the capabilities enabled by MTO. It’s certainly something that seems obvious, but I guess we’ll have to wait until everything matures.
I think the latest Teams client was used but not sure if it was on both sides (testing with a workmate). We’ll definitely check it.
Thanks again for your reply and reminding that we’re still on preview.