If you have worked with more than one Azure AD tenant in the same organization, you know how painful user provisioning between them can get. A company acquires another company, both already run on Azure AD, and now someone has to figure out how employees in tenant A get access to resources in tenant B without duplicating every account by hand. Microsoft’s cross-tenant synchronization feature was built exactly for this problem, and it removes most of the manual work involved in keeping identities aligned across tenants.
This article walks through setting up cross-tenant sync between two Azure AD tenants, the permissions each side needs, and a few decisions you should think through before turning it on. A working sample configuration is linked at the end if you want to reproduce this in your own environment.
Why organizations need this
Mergers and acquisitions are the most common trigger. Two companies, each with their own Azure AD tenant, users, groups, and applications, need to work together without one side migrating everything into the other’s tenant. That kind of full migration is disruptive, slow, and risky, so most organizations prefer to keep both tenants running and build a bridge between them instead.
Cross-tenant synchronization is that bridge, at least for identities. It automatically creates and updates external member users in the target tenant based on the users that exist in the source tenant, so people in the acquired company can be granted access to resources in the parent company’s tenant without a separate manual onboarding step for every account.
Licensing and access requirements
Both tenants need at least an Azure AD Premium P1 license for this feature to work. This is not optional, and it is worth checking before you promise a merger integration timeline to stakeholders, because procurement delays for licensing are common in acquisition scenarios where the acquired company was on a lower tier.
You also need an account and application with the right delegated permissions to configure the sync. Microsoft Graph Explorer is a convenient way to test this out before building anything custom, and that is what was used for the setup described here. For a production rollout, you would typically wrap this in an ASP.NET Core application or a script that your identity team can run repeatedly and audit.
Deciding where identity actually lives
Before touching any configuration screen, decide where the primary identity for each user is going to live. This sounds like a small detail, but it drives every later decision about group membership, conditional access, and application access. Every merge is different, and a many-to-many merge between multiple tenants is considerably harder to reason about than a simple one-directional sync, so keep the design as simple as you can.
A good target architecture has a single source of identity that every application authenticates against, even if that source federates out to other identity providers behind the scenes. Applications should never talk to an external IAM system directly. The one common exception is on-premises applications that cannot reach a cloud IAM system at all, which is a real constraint if one of the merging companies still runs a lot of on-prem infrastructure. Azure AD Connect and Azure AD hybrid setups exist precisely to handle that case.
In the setup described here, both tenants keep their existing identities as the primary definition. Users from the source tenant are added to the target tenant as external member users, and cross-tenant sync keeps that relationship up to date automatically.
Microsoft’s own documentation on this feature is genuinely good, and I would recommend reading it alongside this walkthrough rather than skipping straight to the portal.
Configuring the target tenant
On the target tenant, the user and application performing the setup need these Microsoft Graph permissions:
- Policy.Read.All
- Policy.ReadWrite.CrossTenantAccess
These permissions show up against an enterprise application once the setup completes. That application only exists to create the synchronization, and you can safely delete it afterwards since it is not needed for the sync to keep running. Under the hood, it creates a second enterprise application that actually performs the ongoing synchronization work. You could also skip the Graph Explorer step entirely and configure this directly from the Azure portal if you prefer a UI-first approach.
Configuring the source tenant
The source tenant needs a broader set of permissions, since it is the side actually reading and pushing out user data:
- Policy.Read.All
- Policy.ReadWrite.CrossTenantAccess
- Application.ReadWrite.All
- Directory.ReadWrite.All
Directory.ReadWrite.All is a broad permission, and it is worth flagging to your security team before you request it. In a production rollout, scope the account requesting this down to a dedicated service account used only for the sync setup, rather than reusing a general admin identity that has this permission for other reasons.
Setting the sync scope and attribute mapping
Azure AD provisioning lets you sync every user, or scope it down to a specific group. For this demo, the default was used, which provisions all member users in the source tenant. In a real acquisition scenario, I would almost always scope this to a group instead of syncing everyone on day one, so you can pilot with a small team before rolling it out company-wide.
Attribute mapping follows the same default-versus-custom trade-off you see in most identity provisioning tools. The defaults work fine for a first pass, but check what happens to attributes like department, manager, and job title, since these often drive conditional access policies and group membership rules on the target side.
Watching the sync run
Once configured, changes on the source tenant flow through to the target tenant automatically, within the defined scope. Update a user’s attributes on the source side, and the change shows up on the target side without anyone touching the target tenant directly.
This is where the feature earns its keep. Instead of a helpdesk ticket every time someone joins, leaves, or changes role in the acquired company, the target tenant stays current on its own.
The MFA trust decision
Cross-tenant access settings let you trust the MFA that was already performed in the source tenant, so users are not forced to complete MFA twice when accessing resources across tenants. This is convenient, but treat it as a security decision, not just a configuration checkbox. If the source tenant’s MFA policy is weaker than what your target tenant requires, trusting it effectively lowers your bar without anyone explicitly deciding to do that.
A phishing-resistant MFA method should be the baseline for any organization serious about protecting its users, and that baseline should hold regardless of which tenant a user’s identity happens to originate from. Before enabling MFA trust between tenants, compare both tenants’ conditional access and authentication strength policies side by side, not just their license tiers.
What this does not solve
Cross-tenant sync handles identities. It does not move applications or groups between tenants, and those are usually the next two pieces of a real merger project. Once identities are synchronized, the natural next step is deciding which applications become shared services accessible from both tenants, and how group membership and entitlements get reconciled between the two directories. That is a separate, larger piece of work, and it is worth planning for it rather than assuming identity sync alone completes the integration.
If you are dealing with an ongoing multi-tenant setup rather than a one-time migration, it is also worth looking at access reviews and entitlement management alongside cross-tenant sync, since together they give you a fuller lifecycle story instead of just the provisioning piece.
Leave a Reply