Improving Entra ID B2B User Management with Cross-Tenant Synchronization

B2B user management is a challenge for many organizations that utilize it for collaboration. In this blog, we discuss how to address this challenge using cross-tenant synchronization. Cross-tenant synchronization connects two or more Entra ID (formerly Azure Active Directory) tenants and copies users between them while keeping attributes in sync. In intra-organization collaboration scenarios, such as mergers and acquisitions or affiliated companies, this capability can be extremely helpful. To begin, let’s look at how cross-tenant synchronization can help you.

The B2B User Management Problem

Entra ID B2B collaboration solves the very specific problem of managing external user authentication. However, it still leaves organizations with many B2B user lifecycle management problems because there is no linkage between the B2B user and the source user, as illustrated in the following figure:

This leads to several issues, including:

  • B2B user creation is typically manual; the source user or organization must request access, or the target organization needs to invite the source user. There is no automatic creation of a B2B user tied to the source user role.
  • B2B user attributes are difficult to maintain; limited information about the user is available at onboarding, and changes to the source user are not automatically communicated to the target tenant. This limits the usefulness of any attributes populated about the B2B account since they may no longer be correct.
  • The source organization has no way to revoke B2B accounts for active users (e.g., on a role change).
  • B2B users are not deleted when the source account is deleted.
  • Most B2B users have limited information associated with them, making it difficult to determine why they were created or if they are still needed.

B2B user management thus requires coordination between two organizations to be fully comprehensive. The source organization must notify the target of changes for the user to be properly managed, which can be problematic if the source organization is not aware of the existence of the B2B user, as is often the case.

For many B2B use cases, this disconnect between the source user and the B2B user is actually desirable. If the source organization is only loosely associated with the target, then the target organization may want complete control over the B2B user objects.

Increasingly, though, there are scenarios where the source and target tenant may in fact belong to the same organization—as the result of a merger or just as independent implementations of Entra ID by different business units. In such cases, it may be appropriate to trust the source tenant for more than just the user authentication that B2B collaboration provides.

Cross-Tenant Synchronization

Cross-tenant synchronization allows a source tenant to define a set of users who are in scope of synchronization to a target tenant as B2B users, and the set of attributes that will be synchronized (and optionally transformed) to that target tenant. The target tenant merely consents to accept the users to be synchronized from the source tenant.

No other scenarios are supported at this point: no synchronization of groups, devices, or other objects. The two tenants involved in a synchronization must be in the same cloud, with only the commercial cloud currently enabled.

Although limited, this does allow a multi-tenant organization to move the management of B2B users into the tenants they are sourced from, instead of the tenant where they are hosted. The following figure illustrates this point:

This addresses many of the user management deficiencies that exist with B2B accounts today:

  • The lifecycle of the B2B account is tied to the lifecycle of the source account. The creation of a source account can trigger a B2B account creation, and source account deletion will trigger deletion of associated B2B accounts. Since in most cases the source account is subject to some kind of lifecycle process already (automated or not), this effectively transfers that process to any associated B2B accounts.
  • It is possible to revoke an active user’s B2B access by moving them out of scope of the synchronization configuration, resulting in the B2B account being deleted. This can be useful if only certain roles or jobs need to have cross-tenant access.
  • By synchronizing attributes between the tenants, it is possible to control access in the target tenant to resources from the source tenant (e.g., by using dynamic groups that reference the synchronized attributes).
  • Attribute synchronization improves the information available in the target tenant about who the B2B users are (e.g., to administrators making access decisions or regular users viewing the global address list).

Cross-Tenant Topologies and Scenarios

Cross-tenant synchronization is a one-way arrangement that pushes regular users from one tenant into B2B users in another tenant. Since B2B users can never be in scope of an outbound cross-tenant synchronization configuration, there is no risk of synchronization loops or conflicts. This allows a lot of flexibility with the topologies that can be implemented.

Some sample topologies and use cases are illustrated in the following figure:

Outbound  Push from a central tenant to all other tenants (e.g., for publishing administrative accounts in a multi-tenant environment)  
Inbound  Push from all other tenants to a central tenant (e.g., for enabling access to applications hosted in the central tenant)  
Full Mesh  Synchronization from all tenants to all other tenants (e.g., for full cross-tenant collaboration)  
As Needed  Tenant synchronization configurations created as needed for access (e.g., for when access requirements are more complex than the previous three scenarios)

When Not to Use Cross-Tenant Synchronization

Microsoft does not recommend using cross-tenant synchronization outside of an organization. The documentation includes the somewhat cryptic statement “For privacy reasons, cross-tenant synchronization is intended for use within an organization.

More practically, cross-tenant synchronization does not allow the target tenant to implement any controls on the data that is synchronized from a source tenant once the synchronization configuration is created.

This creates the risk that the source tenant could (accidentally or maliciously) create B2B accounts that:

  • Have attribute values that qualify them for dynamic groups that grant unwarranted permissions
  • Mimic high-value accounts (e.g., the CEO)
  • Create excess volume of entries (e.g., a tenant with 80,000 users syncing all users into a tenant with 500 users)

Although there are ways to mitigate these risks, as long as there are no controls at all on the inbound data synchronization, it seems prudent to restrict the capability to tenants that are part of the same overall organization.

Summary

Cross-tenant synchronization represents an excellent opportunity to reduce the complexity of administering B2B users in a multi-tenant organization. For assistance with this and other Azure identity management scenarios, contact the experts at Ravenswood Technology Group.

[RELEVANT BLOG CONTENT]

6 Tips to Harden Your Windows LAPS Deployment

In a previous blog post, we covered how to migrate to Windows Local Administrator Password Solution (LAPS). With Windows LAPS deployments gaining traction, it’s important

Migrating to Windows LAPS

Windows Local Administrator Password Solution (LAPS), now integrated into the OS, is the replacement for Microsoft LAPS, which was a separate installation. Windows LAPS is

Leave a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.