Microsoft’s Cross-tenant storyline
Microsoft has a good road map so far on the Cross-tenant access features, no more External users or switching between Teams tenants when you need access to multiple ones and we all know we do need multiple of them.
If using with your own user account, the target tenant can allow to trust your MFA and you will be getting only one prompt. This will depend on whether the user is completing MFA in their home tenant or the resource tenant, different authentication techniques can fulfill authentication strength in external user scenarios. See in the below table the supported methods.
Only the claims indicated in the “Home tenant” column below will be accepted by the resource tenant for MFA if a resource tenant has chosen to trust claims from external Azure AD organizations. The external user must complete MFA in the resource tenant using one of the procedures provided in the “Resource tenant” column if the resource tenant has disabled MFA trust.
|Authentication method||Home tenant||Resource tenant|
|SMS as second factor||✅||✅|
|Microsoft Authenticator push notification||✅||✅|
|Microsoft Authenticator phone sign-in||✅||✅|
|OATH software token||✅||✅|
|OATH hardware token||✅|
|FIDO2 security key||✅|
|Windows Hello for Business||✅|
B2B direct connect
A feature of External Identities called Azure Active Directory (Azure AD) B2B direct connect enables you to establish a mutual trust connection with another Azure AD business to facilitate easy collaboration.
Teams Shared Channels
See overview on shared channels, they will be provisioned using B2B direct connect feature mentioned earlier.
And how to create them inside Teams
Cross-tenant access settings
Azure AD companies can employ External Identities cross-tenant access settings. You have fine-grained control over how external Azure AD organizations interact with you (inbound access) and how your users interact with external Azure AD organizations thanks to cross-tenant access settings (outbound access).
Cross-tenant User Data Migration
Microsoft released Cross-tenant user data migration last year. As an overview, you can migrate from tenant to tenant users mailboxes and OneDrive content.
You can read more on my previous blog concerning this feature.
So, cross-tenant has been a hot topic for a while now and now it’s time for next feature to the cross-tenant family.
What is Cross-tenant synchronization?
Creating, updating, and deleting Azure AD B2B collaboration users across tenants in an organization is automated through cross-tenant synchronization. Users may access applications and work together across tenants, and the organization can still develop thanks to it.
The following objectives of cross-tenant synchronization are crucial:
- Collaboration that is seamless for a multi-tenant business
- Automate B2B collaboration user lifecycle management in a multi-tenant company.
- Delete B2B accounts instantly if a user leaves an organization.
What Azure cloud are supported?
- Cross-tenant synchronization is supported within the commercial and Azure Government clouds.
- Synchronization is only supported between two tenants in the same cloud.
- Cross-cloud (such as public cloud to Azure Government) isn’t currently supported.
Who should use it?
Organizations have different needs from different reasons. Currently Microsoft advises only clients with the following to use this feature
- Organizations that own multiple Azure AD tenants and want to streamline intra-organization cross-tenant application access.
- Cross-tenant synchronization is not currently suitable for use across organizational boundaries.
Maybe in the future they will be more “supported” use cases for this excellent feature.
What you need for it?
- A source Azure AD tenant with a Premium P1 or P2 license
- A target Azure AD tenant with a Premium P1 or P2 license
- An account in the source tenant with the Hybrid Identity Administrator role to configure cross-tenant provisioning
- An account in the target tenant with the Hybrid Identity Administrator role to configure the cross-tenant synchronization policy
What topologies are supported?
Cross-tenant synchronization can provide a flexible solution for collaboration by allowing users to share data and access resources across different tenants. However, it’s important to note that every organization has unique requirements and needs, and the configuration of cross-tenant synchronization should be tailored to fit those needs. Each cross-tenant synchronization configuration is one-way, meaning that it only synchronizes data in one direction between two Azure AD tenants. This allows for different topologies to be configured, such as:
- Synchronizing users from one tenant to another
- Synchronizing groups and group membership
- Synchronizing resources such as calendars and contacts
- Synchronizing attributes such as name, email address, and phone number
However, it’s important to keep in mind that cross-tenant synchronization can be a complex process and that it can have security, compliance and management implications. It’s important to be familiar with the tenants and the data, and to have a good understanding of the security and privacy requirements, before setting up cross-tenant synchronization.
Attributes of the feature:
- Based on the Azure AD provisioning engine.
- Is a push process from the source tenant, not a pull process from the target tenant.
- Supports pushing only internal members from the source tenant. It doesn’t support syncing external users from the source tenant.
- Users in scope for synchronization are configured in the source tenant.
- Attribute mapping is configured in the source tenant.
- Extension attributes are supported.
- Target tenant administrators can stop a synchronization at any time.
Single source -> single target
The simplest topology where users in a single tenancy need access to the parent tenant’s applications is shown in the example below.
Single source -> multiple targets
The example below illustrates a central user hub tenant where users need access to programs in smaller resource tenants spread around your company.
Multiple sources -> single target
The example below illustrates freshly acquired tenants where users from various tenants require access to the parent tenant’s apps.
Your company might have a mesh-like level of complexity. The topology in the example below depicts how users move between tenants inside their company. This topology is frequently used to provide scenarios for persons searches in which each user must be a part of each tenant in order to have a unified gallery.
When an application uses automatic user provisioning, Azure AD automatically creates and updates user accounts in the app based on criteria like user and group assignment at predetermined intervals, usually every 40 minutes and this time is what Cross-tenant synchronization uses and it can’t be currently changed.
See more on App based provisioning
How to setup?
Target tenant setup
Currently there is no direct menu to go Inside Entra. For this reason I will show the setup with old style Azure portal.
You will find the solution from https://portal.azure.com/#view/Microsoft_AAD_Connect_Provisioning/CrossTenantSynchronizationMainMenuBlade/~/Configurations
From there you can create a configuration (App registration)
Give it a descriptive name. I will add App in the name and soon you will see why
And during the setup there will be a reminder that the feature is still in preview, just refresh your screen an it will be fine
Once refreshed, you see the created configuration
Once you open the configuration, you will see the following configurable options under it
Under provisioning you can change from Manual to Automatic but during Preview you cannot change it back. I will keep it manual for now.
Let’s jump to Entra and I will show you why I named it as application. Open App registrations under Entra and you will see an familiar App registration.
And we can see it also under Enterprise applications, just wanted to share this so you understand what we are dealing with
Again jumping back to Azure portal and now under https://portal.azure.com/#view/Microsoft_AAD_IAM/CompanyRelationshipsMenuBlade/~/CrossTenantAccessSettings
Choose “Allow users sync into this tenant” to allow sync
And under the organizational config open Trust settings
Suppress consent setting must be checked in both the source tenant (outbound) and target tenant (inbound)
Source tenant setup
Add users that you want to sync to App registration as users, either in the configuration or under Enterprise applications
In the source add cross-tenant sync application and switch mode to Automatic
And the copy Tenant ID of the target tenant, you can do this with Entra, Azure portal or with the following page
Then click on “Test connection” and you will be presented with an error or success, my case success!
Once test is done, hit save and you will see more menus under the application
For mapping (that you can edit) and for notification email and threshold for deletion
You can remove mapping or add new ones
See more from Microsoft on the mapping and how it works
And you have advanced options like request additional attributes, use expression builder and review your schema as JSON.
Schema export allows you to edit or download your schema
You can test out the provisioning from Provision on demand with 5 selected users at the time
Once you select the users and run demand provisioning, you will see the following error if the user isn’t attached to the app registration
Once the user is added, you can see them inside the provisioning page
And the will be provisioned, you can see the details at attribute level and the data flow on what attributes have been provisioned
Once you are done, switch that sync to On to schedule it every 40 mins.
And start the initial sync
Once the user is provisioned, you will the status of the different parts inside the status page and the provisioning logs are one the left side
When you open the logs, you will see skipped and successful syncs
Application owners can view logs for their own applications. The following roles are required to view provisioning logs:
- Reports Reader
- Security Reader
- Security Operator
- Security Administrator
- Application Administrator
- Cloud Application Administrator
- Global Administrator
- Users in a custom role with the provisioningLogs permission
What isn’t supported?
- Restoring a previously soft-deleted user in the target tenant
- Synchronizing groups, devices, and contacts into another tenant
- Synchronizing users across clouds
- Synchronizing photos across tenants
- Synchronizing contacts and converting contacts to B2B users
- An external user from the source (home) tenant can’t be provisioned into another tenant. Internal guest users from the source tenant can’t be provisioned into another tenant.
- Provisioning manager attributes isn’t supported.
- Configuring synchronization from the target tenant
- Directory extensions and the appRoleAssignments, userType, and accountExpires attributes aren’t supported as scoping filters.
- Provisioning passwords isn’t supported.
- Provisioning nested groups isn’t supported.
- Provisioning to B2C tenants isn’t supported because of the size of the tenants.
And the limitations
- It’s possible for synchronized users to appear in the global address list (GAL) of the target tenant for people search scenarios, but it isn’t enabled by default. In attribute mappings for a configuration, you must update the value for the showInAddressList attribute.
- B2B users are unable to manage certain Microsoft 365 services in remote tenants (such as Exchange Online), as there’s no directory picker.
- Unable to change provisioning mode back to manual
- The attributes SamAccountName and userType aren’t available as a source attribute by default
- Source attribute dropdown missing for schema extension
- Null attribute can’t be provisioned
- Attribute-mapping expressions can have a maximum of 10,000 characters.
- Multivalued directory extensions can’t be used in attribute mappings or scoping filters.
- The Global Reader role is unable to read the provisioning configuration. Create a custom role with the
microsoft.directory/applications/synchronization/standard/readpermission in order to read the provisioning configuration from the Azure portal.
Cross-tenant story keep expanding and these are really useful features in the world of acquisitions and mergers.
Try it out for our self and give feedback to Microsoft if something isn’t right or shout it out in social. These things are developed for us all to have easier life as Cloud professionals.
Have a good one!