The article looks at and explores the new Azure AD cross-tenant synchronization. The feature makes it really easy to implement the technical part of synchronization between different Azure AD tenants.

Code: https://github.com/damienbod/Aad-cross-tenant-synchronization

Requirements

To use this feature, both the source tenant and the target tenant require at least a P1 Azure AD license. The administrator and the application used to implement the feature needs to have the required delegated authorization. I used Microsoft Graph Explorer for this. In a second step, I will implement an ASP.NET Core application for this.

Setup

In this use case, I have two separate tenants with users, applications, groups and everything that comes with an Azure AD tenant. I would like to join these two tenants without migrating all the users, groups, and applications to one of the tenants.

A typical use case for this would when a company acquires a second company and both use Azure AD. There are many different strategies for technically merging two companies and every implementation is always different. The merge might be a m-n merge which is a more complicated to implement. It is always best to aim for simplicity. I always aim to reduce to a single source of identity for applications and use this to authenticate everything against. The single source of identity can federate to different IAM systems, but the applications should not use the external IAM directly.

I also try to have only one source of identity for users, but this is not always possible. With these complex systems, users must have only one primary identity, otherwise it gets really hard to maintain onboard, offboard and you require more tools to manage this. One problem with this solution is using on-premise applications or clients with cloud IAM solutions. For some on-premise applications, there is no network connection to the cloud systems and so exceptions needs to be implemented here if using a cloud solution as the single source of identity for applications. Azure AD and AD is one such example of this problem and Microsoft provide a good solution for this. (Azure Hybrid)

The big decision is deciding where the identities have the primary definition.

In this demo, we keep the identities primary definition as it was and add the members of the source tenant to the target tenant as external member users. This synchronized then.

The Microsoft documentation for this is excellent and I really recommend using this when implementing the synchronization.

Setup target tenant

To implement the synchronization, the user and application need the assigned privileges for the following Microsoft Graph permissions:

• Policy.Read.All
• Policy.ReadWrite.CrossTenantAccess

You can view this in the Enterprise applications once setup. This Enterprise application is only required to create the synchronization. This can also be deleted after the synchronization has been created. The Enterprise application is used to create a second Enterprise application used for the synchronization. You could also just implement this directly in the Azure portal.

The different steps to create the synchronization are described in great detail in the Microsoft Azure docs.

Setup source tenant

To implement the synchronization, the user and application need the assigned privileges for the following Microsoft Graph permissions:

• Policy.Read.All
• Policy.ReadWrite.CrossTenantAccess
• Application.ReadWrite.All
• Directory.ReadWrite.All

The different steps to create the synchronization are described in great detail in the Microsoft Azure docs.

Synchronization configurations

The Azure AD provisioning can be setup to add all users, or scoped to a set of users, or a group of users as required. The provisioning can be setup to map the user attributes as required. I used the default settings and provision all member users.

Synchronization in operation

One the synchronization is setup, the identities are automatically updated to the target system using the defined scope and configuration. You can make changes on one tenants and the changes can be viewed on the target tenant. The trust settings can be updated to trust the original MFA form the source tenant, but care needs to be taken here. You do not want to allow weaker MFA than the required company policy. A phishing resistant MFA should be standard for any professional company that cares about its employees and security.

Now that the identities are synchronized , the next step would be to move the applications and the groups for the shared services.

Links

https://learn.microsoft.com/en-us/azure/active-directory/multi-tenant-organizations/cross-tenant-synchronization-overview

https://learn.microsoft.com/en-us/azure/active-directory/multi-tenant-organizations/cross-tenant-synchronization-configure

https://learn.microsoft.com/en-us/azure/active-directory/multi-tenant-organizations/cross-tenant-synchronization-configure-graph

https://www.microsoft.com/en/security/business/identity-access/azure-active-directory-pricing