Configuring Entra ID Cross-Tenant Synchronization

Synchronizing Entra ID User Account Information Between Tenants

Recently, I have had many projects originating from business mergers and acquisitions (M&As). Many of these projects involve Microsoft 365 tenants. The key to an M&A project is identity, and this article discusses how Entra ID deals with cross-tenant synchronization in the context of an M&A project.

M&A or separation projects involve two or more Microsoft 365 tenants. To support user access to resources (like Teams channels or SharePoint sites) which have moved to another tenant, we need to create guest user accounts in each tenant because that’s the basis of how Entra ID B2B collaboration works. We can create guest accounts manually or with PowerShell. However, it’s not practical when working with thousands of users in both tenants. We need a way to update each tenant when a change occurs. In the old days, we would install and configure a Microsoft Identity Manager (MIM) or third-party solution to support directory synchronization. Now the Entra ID Cross-Tenant Sync feature makes things a lot easier.

What is Entra ID Cross-Tenant Sync?

Entra ID Cross-Tenant Sync is a cloud-based service to support B2B scenarios and when organizations have multiple tenants. The service is available with Azure AD Premium P1 or P2 licenses.

Entra ID synchronizes tenant directories every 40+ min using the information defined in the cross-tenant synchronization configuration. The interval is fixed and controlled by Microsoft. Note that the configuration only represents synchronization in one direction. If you have two tenants and want bidirectional synchronization between the two tenants, you must set up synchronization in both tenants. In Figure 1 you can see the list of configurations defined in a tenant.

You can add as many configurations for synchronization targets as possible within your tenant. Each configuration presents a synchronization direction to push updates from one tenant to another. When you plan your deployment, note the limitations or unsupported scenarios listed here. Below are the key limitations at the time of writing:

• Only supports synchronization of users (in source tenant) to guest users (in target tenant).
• Does not support synchronizing contacts and groups.

This may be important as many of my client deployments involve some kind of contact objects in their tenant. Not to mention all tenants have some groups.

Configuration of the Target Tenant

All the configuration steps mentioned so far are for the source tenant. What about the target tenant? There are two actions we need to take before synchronization is possible. Note that synchronization will not start until we tell Entra ID to begin.

In the target tenant, apply two settings to the cross-tenant access policy for the source tenant:

• Automatically redeem invitations with the tenant in the Entra ID Inbound access settings. This is to prevent Entra ID from sending email to synchronized users from the target tenant (or all tenants) by asking the user to consent for their account to be added to the target tenant (figure 2).

• Allow User sync into this tenant in the Entra ID Inbound access settings. This setting is to allow cross-tenant sync to write identity into your tenant (figure 3).

Enabling the Cross-Tenant Sync

After the target tenant is prepared, all you need is to set up a configuration is the identifier of the remote tenant. The identifier is a GUID that the tenant administrator can find in the Entra ID overview page or by running the Get-MgOrganization cmdlet. Enter the GUID in the configuration screen (figure 4).

After testing the connection to confirm the identifier value, Entra ID can create the configuration. Next, we will need to adjust some other user provisioning settings before we can start synchronization.

Attribute Mapping

Synchronization of an identity database is not an easy task. Luckily, we are dealing with synchronization between the same database type. There is no need to worry about things like data type differences. However, we need to pay special attention here. Often, we see enterprises using attributes in different ways. For example, one of my clients put the company name in the department and uses the company name to store the region the user belongs to. The key takeaway is to make sure when you create a synchronization configuration, take some time to map user attributes between tenants. Figure 5 shows the result of mapping attributes between two tenants.

In most situations, the default mapping, as shown in Figure 5, works. One adjustment I always add is the mapping of the userType field. This is the field to control types of users (guest users or full B2B users). The possible values are Guest and Member. If you are handling M&A projects, we must set the userType field to Member to force Entra ID to consider the users created by Cross-Tenant sync as internal users. At the moment there are not many differences in different services when userType is set to Member or Guest. But Microsoft will be updating the services to provide a different experience when userType is Member or Guest.

Another thing to note is that attribute mappings are defined for the source tenant. In other words, the attribute mappings define how users from your tenant will appear in the target tenant. Remember the need to do the same setting on the other side.

Synchronization Scope

If you have large tenants, you may want to control which users synchronize with the target tenant. By default, Entra ID synchronizes all users to the target tenant. If you need to specify which users to include in synchronization, change the scope setting so Entra ID will write only users assigned to the configuration to the target tenant (figure 6).

You can create a group specifying the users to include in the synchronization and assign them to the configuration, as shown in Figure 7. Of course, you can also assign users individually, but I do not recommend doing this for manageability reasons.

Let’s Start the Sync

At this stage, you are all set to start synchronization. Open the configuration for the target tenant and click Start Provisioning. Wait for up to 40 minutes for the first synchronization to complete.

You can check the progress and status by looking at the provisioning log, as shown in Figure 8.

In the log, you can see what’s happening for each object and if they are created or skipped (figure 9). Skipped usually means the object already exists or is not a supported type. You are also able to view the detailed changes performed by Cross-Tenant Synchronization by clicking the entry. For example, a user is skipped because it’s not in the synchronization scope (figure 10). You can also view the properties that are modified as part of this provisioning.

You can also consider using Graph API to query the provisioning log, which the details are available here.

Summary

Entra ID Cross-Tenant Sync makes it easier to handle multi-tenant configurations or projects. This solution removes the need for any on-premises servers as processing takes place in the cloud. This feature helps make multi-tenant deployment possible in an organization. Now let’s see when Microsoft will deliver support to synchronize groups and contacts in future releases, as a cloud-based tenant-to-tenant sync would be a perfect solution for organizations that have needs for multi-tenant deployment.