Entra ID / Azure AD - Cross-tenant Synchronization
Does an organisation you're working within (or for) comprise multiple Microsoft 365 / Azure tenants? Is collaboration proving somewhat cumbersome and difficult to manage? Perhaps the business recently acquired another company or employ multiple tenants to accommodate structural, vanity, or data protection requirements. Whilst a full-scale tenant-to-tenant migration and merger would always be preferable, this isn't always immediately feasible or possible. Considering this, the only solution to introduce collaboration and access between these tenants previously was to implement Entra ID's (Azure AD) B2B offering via Cross-tenant access settings and Entitlement management. Options have recently improved, however. Announcing Entra ID's Cross-tenant synchronization feature, a new component offering enhanced user provisioning and collaboration capabilities between tenants governed by a single enterprise, welcoming a competent stop-gap in the absence of a complete merger.
Whilst business-to-business (B2B) technology did exist before the release of Cross-tenant synchronization, as alluded to with Cross-tenant access settings and Entitlement packages, these components primarily intended to facilitate collaboration between an organisation and a third party, i.e., a company tenant and a supplier tenant. Cross-tenant synchronization, on the other hand, intends to facilitate collaboration between tenants owned by the same entity. However, Cross-tenant access isn't made entirely redundant here, in fact, Cross-tenant synchronization is based upon this technology utilising its collaboration toolset and security controls. Whilst on the latter note of security, all synchronized users can benefit from Conditional Access protection within the destination tenant as normal, but with the added capability of Cross-tenant access settings to establish trust between both tenants when it comes to specific grant conditions, such as Multi-factor Authentication, device compliance, and device Hybrid join.
Cool. So what does Cross-tenant synchronization actually accomplish? Essentially, it enables one or more tenants to synchronize their user objects into another tenant, provisioning them in the first instance and then routinely synchronizing them thereafter to accommodate any future user property or attribute changes. Functionality doesn't terminate at user creation either, with end-to-end lifecycle management provided through the de-provisioning and deletion of users too. It's this very user provisioning capability into the inbound tenant that qualifies them to access the resource within there; this access to resource includes but is not limited to, SharePoint Online, Microsoft Teams, and any configured third-party SAAS applications such as Adobe, Google Workspace, HR tooling, or even Azure App Proxy applications. Other minor but useful additions include the ability to own a complete, dynamic, and company-wide Global Address List within the inbound tenant, without reliance on static mail contacts, as well as the ability to include synchronized users within other mail objects such as Distribution Lists, again negating static mail contacts. Another significant advantage of this provisioning model is the improvement to the end users' experience which becomes considerably more seamless, as users no longer have to accept numerous collaboration invitations via e-mail, accept consent prompts, or satisfy MFA for both the inbound and outbound tenants, as a trust can be established between entities to trust the fulfilment of MFA within the source, thus not prompting again in the destination.
To clarify: - It's important to recognise that Cross-tenant synchronization operates a PUSH model only, not PULL, or PUSH and PULL, meaning provisioning only functions one way from the outbound (source) tenant into the inbound (destination) tenant. Therefore, the inbound tenant maintains no visibility into the source.
Let's jump into Endpoint Privilege Management: -
Prerequisites
Licensing
The outbound (source) tenant requires an Entra ID (Azure AD) Premium P1 license per synchronized user.
The inbound (destination) tenant relies on the Entra ID External Identities billing model, detailed here: - MAU billing model for Azure AD External Identities. The inbound tenant also requires at least one Entra ID Premium P1 license to enable auto-redemption.
Scenario
First, let's establish a scenario to introduce context to the configuration we'll be conducting. We'll be focusing on a one-to-one synchronization model where one tenant needs to seamlessly collaborate with another.
An organisation called Three Sixty Thrive maintain a Microsoft 365 tenant using the domain threesixtythrive365.com which hosts the company's users, endpoints, data, applications, and services.
Recently, Three Sixty Thrive acquired another organisation called Three Sixty Thrive Test. Three Sixty Thrive Test also maintain their own Microsoft 365 tenant with the domain threesixtythrivetest.onmicrosoft.com which hosts the company's resources. As illustrated in the diagram below, two users exist within this subsidiary tenant, Fred and Mary, both of whom need to seamlessly collaborate with users and access resources within the acquiring organisations' tenant, threesixtythrive365.com.
By default, our scenario so far implies that the acquired company, Three Sixty Thrive Test, will become the outbound (source) tenant, being the source for the synchronization and provisioning action, with Three Sixty Thrive becoming the inbound (destination) tenant where the users will be provisioned into. To facilitate this, we'll configure the cross-tenant synchronization feature to provision users from the threesixtythrivetest.onmicrosoft.com tenant into the threesixtythrive365.com tenant, all without compromising security and whilst ensuring users obtain suitable access to fulfil their job roles. We'll also look at how to manage the synchronization of these users and their attributes going forward to accommodate any housekeeping and technical requirements.
Cross-tenant access - Inbound
Tenant: Inbound (Destination)
Cross-tenant access settings lay the foundations for the cross-tenant synchronization capability. Cross-tenant access settings determine how different tenants can collaborate with each other on both an inbound and outbound basis, granting control over how external entities can collaborate with you, and how internal entities can collaborate with others. Cross-tenant settings provide a configurable default option for all established B2B connections, but can also support unique settings per connection. Furthermore, these settings also offer the ability to establish trusts between tenants to accommodate various conditional access conditions such as MFA and device claims, i.e. Hybrid AAD Join and Compliance. These trusts authorise users from the source tenant to satisfy certain Conditional Access conditions enforced by the destination tenant, meaning security doesn't need to be compromised.
First, we'll look at configuring the required cross-tenant access settings in the inbound (destination) tenant, threesixtythrive365.com.
1. Within the Microsoft Entra blade, expand Identity, expand External Identities, and then select "Cross-tenant access settings".
2. Next, navigate to the "Organizational settings" tab and then select "Add organization".
3. Within the fly-out pane on the right-hand side, enter the outbound (source) tenant's ID or verified domain, and then click "Add" after verifying the resulting tenant details.
The ID of a tenant can be located within the Microsoft Entra blade, specifically within Identity - Overview.
4. Once the organisation connection has been established, click the "Inherited from default" link under the inbound access column. Remember, as this is the destination tenant, we are configuring the inbound settings.
5. Within the inbound access settings for the connected tenant, navigate to the "Trust settings" tab and check the latter option to "Automatically redeem invitations with the tenant *Tenant Name*". Enabling this setting enables the automatic redemption of invitations so that end-users don't have to accept the usual consent prompt themselves the first time they access the inbound (destination) tenant.
Within this tab, there is also the option to either adopt the default (but configurable) settings or specify custom settings for the enablement of trusts to accommodate various conditional access conditions such as MFA and device claims. Within this example, we have opted to trust Multi-factor authentication claims from the outbound (source) tenant, which will prevent users from having to satisfy MFA twice, once for each tenant.
For reference, the default cross-tenant access settings can be found and configured back at the main "Cross-tenant access settings" page within the "Default settings" tab.
6. Finally, within the next tab "Cross-tenant sync", check the "Allow users sync into this tenant", and then click "Save". Enabling this tenant allows users to synchronize and provision from the outbound (source) tenant, which in turn facilitates the cross-tenant synchronization capability.
Cross-tenant access - Outbound
Tenant: Outbound (Source)
Much like we performed in the previous section, Cross-tenant access - Inbound, we'll now look at configuring the required cross-tenant access settings within the outbound (source) tenant, threesixtythrivetest.onmicrosoft.com.
1. Within the Microsoft Entra blade, expand Identity, expand External Identities, and then select "Cross-tenant access settings".
2. Next, navigate to the "Organizational settings" tab and then select "Add organization".
3. Within the fly-out pane on the right-hand side, enter the inbound (destination) tenant's ID or verified domain, and then click "Add" after verifying the resulting tenant details.
To locate the ID of a tenant, please refer to Step 3 within the previous section.
4. Once the organisation connection has been established, click the "Inherited from default" link under the outbound access column. Remember, as this is the source tenant, we are now configuring the outbound settings.
5. Within the outbound access settings for the connected tenant, navigate to the "Trust settings" tab and check the latter option to "Suppress consent prompts for users from the other tenant when they access apps and resources in my tenant". Enabling this setting enables the automatic redemption of invitations so that end-users don't have to accept the usual consent prompt themselves the first time they access the inbound (destination) tenant.
Cross-tenant synchronization
Tenant: Outbound (Source)
Now that we've established the Cross-tenant access settings, it's time to configure the actual Cross-tenant synchronization capability. The cross-tenant synchronization caters for the synchronization and provisioning of users, from enabling the feature to controlling and managing the synchronization events. In this particular section, we'll focus on establishing the cross-tenant synchronization connection first, focusing on the control and management aspects within the following sections of this post.
Cross-tenant synchronization is to be enabled and configured within the outbound (destination tenant), which in this case is threesixtythrivetest.onmicrosoft.com.
1. Within the Microsoft Entra blade, expand Identity, expand External Identities, and then select "Cross-tenant synchronization".
2. Next, navigate to the "Configurations" tab and then select "New configuration".
3. Within the New cross-tenant synchronization wizard, specify a name for the connection and then click "Create". Wait for the configuration to propagate.
4. Once the new configuration has completed propagating, click to open it, and then click "Get Started".
5. Clicking "Get Started" will present the "Provisioning" configuration pane. First, change the "Provisioning Mode" to Automatic. Next, within the "Admin Credentials" subsection, enter the inbound (destination) tenants ID. To locate the ID of a tenant, please refer to the instructions detailed here. Once populated, click the "Test Connection" button to verify all the previous configurations. If testing fails, please confirm all previous instructions.
Upon a successful test result, click "Save" - The "Settings" subsection will be reviewed later.
6. To further confirm the successful establishment of cross-tenant synchronization with the outbound (source) tenant, verify the creation of an Enterprise Application in Identity - Applications - Enterprise applications. The application will be named accordingly with the name chosen in Step 3 within this section. If you've ever configured an Enterprise Application before, such as SSO / Provisioning, you will be familiar with this blade.
Provisioning mappings & attributes
Tenant: Outbound (Source)
Through leveraging the newly created cross-tenant synchronization configuration and associated Enterprise application, we'll now look into the available configuration for the end-user object mappings & attributes which are taken into consideration during synchronization events. It's perfectly acceptable to run with the default attribute mappings, however, it may prove beneficial to modify certain existing attributes or create new ones where appropriate. Such changes may help to identify and distinguish any synchronized entities within the inbound (destination) tenant, as well as aid any technical requirements such as dynamic group rules.
1. Access the "Provisioning" tab of the previously created cross-tenant synchronization configuration. This configuration can either be accessed through the cross-tenant synchronization blade or through the Enterprise applications blade. Once within the "Provisioning" tab, expand the "Mappings" subsection and click "Provision Azure Active Directory Users".
2. Next, within the "Attribute Mapping" page, scroll down to the "Attribute Mappings" sub-heading.
Observe the two columns, Azure Active Directory Attribute and Azure Active Directory (target tenant) Attribute. The first column reflects the user object attribute (property) within the outbound (source) tenant, and the latter column reflects how the user object attribute will be reflected within the inbound (destination) tenant. For example, we can see that the "city" attribute (and value) for each synchronized user from the outbound tenant will map to the same "city" attribute within the reflected inbound tenant's user object.
Each of these attributes can be amended as per your requirements, if required. Additionally, there is also the option to create new attribute mappings using the custom "extensionattribute" attributes. Within each attribute mapping, you can also specify how the synchronization behaves, i.e., should the attribute and value always verify / update during every synchronization event, or only upon the initial creation of the user object.
An example of tweaking an existing attribute mapping could be the modification of the department attribute for the synchronized object in the inbound (destination) tenant, i.e., you could suffix the already populated department value with the secondary organisations' name. For example, rather than simply persisting with the "Finance" value for the department attribute between both tenants for a user, you could provision the user into the inbound tenant with a department value of "Finance - TEST". It's important to understand that in this example, the attribute within the outbound tenant would remain as is, i.e., Finance, as this change will only impact the value within the inbound tenant for the synchronized user. This same concept applies to all other attributes too.
Take a moment to review these mappings as there are numerous ones to note, such as "showInAddressList" which can determine whether the provisioned user object will be visible within the recipient tenants Exchange Global Address List. We'll take a look at modifying an existing attribute mapping, as well as creating a new one, in the following steps.
3. The first mapping we'll concentrate on is the "userType" attribute. Notice that the default value is "member" rather than "guest". This is because we're deploying cross-tenant synchronization; intended to facilitate collaboration between tenants belonging to the same organisation/s. Therefore, users are recognised as "members". Usually, Guests are reserved for third parties where cross-tenant access or B2B invitations are delivered without synchronization capabilities.
Optionally, adjust the provisioning behaviour from the default configuration, "Only during object creation", to "Always". Otherwise, with the default configuration in situ, the value of the attribute would only append upon user creation and not during any subsequent synchronization events. Therefore, if a user-object existed in the inbound tenant already, perhaps from a previous B2B guest invitation, this new value of "Member" wouldn't override as the user would be already present. To remediate this, and to ensure all target users provision as members, set this mapping to "Always".
Click Ok to be returned to the attribute mapping selection page.
Tip: Consider any Conditional Access policies which may target member and/or guest accounts differently.
4. Next, for the purposes of demonstrating the modification of an existing mapping, we'll take a look at appending a suffix of "- TEST" to the "displayName" attribute. This amendment will change the way the user object displays in the inbound (destination) tenant, but will not affect the existing attribute value in the outbound (source) tenant. In this example, a user has a display name of "Fred" in the source tenant, however, this will become "Fred - TEST" within the recipient tenant.
Within the attribute editor for "displayName", we'll change the "Mapping type" to "Expression" and then add the following Expression: -
Append([displayName], " - TEST")
For further assistance building expressions, you can use the expression builder by clicking "Use the expression builder" as illustrated above and below. This expression builder can be used to create and test various expressions.
Within the above screenshot, at the bottom, we can see see the test output appended the "- TEST" value to the users' display name.
Please refer to the following Microsoft Learn article for further information about expressions: -
4. Once any optional amendments have been made to the existing mappings and saved, we can then take a look into creating a new attribute mapping.
In this example, we'll create a new attribute mapping which will reflect a value matching the subsidiary tenants / organisation's name within the inbound (destination) tenant. We'll then be able to leverage this attribute to report on, as well as to populate a dynamic group for these synchronized users.
At the bottom of the "Attribute Mappings" table, click "Add New Mapping".
Within the attribute editor, select "Constant" as the mapping type and then enter the desired value into the "Constant value" text field. In this case, we'll use the name of the subsidiary organisation's tenant. Once the value has been populated, select a "Target attribute" to map this newly specified value to. In this example, we'll map the value to one of the reserved & custom "extensionAttribute" attributes, extensionAttribute5.
Once all the required configuration has been finalised, click save to create the new attribute mapping.
As a reference, please find the following details regarding the different "Mapping types": -
Direct – The target attribute is populated with the value of an already present attribute belonging to the linked object within Entra ID / Azure Active Directory.
Constant - The target attribute is populated with a specific string chosen by the IT admin.
Expression - The target attribute is populated based on the result of a script-like expression.
None - The target attribute is left unmodified. However, if the target attribute is ever empty, it's populated with the default value chosen by the IT admin.
Provisioning settings
Tenant: Outbound (Source)
Once the provisioning mappings and attributes have been reviewed, amended, created, and/or confirmed, it's time to move on to the Provisioning settings.
Access the "Provisioning" tab within the previously created cross-tenant synchronization configuration. This configuration can either be accessed through the cross-tenant synchronization blade or through the Enterprise applications blade. Once within the "Provisioning" tab, expand the "Settings" subsection.
Within the Settings subsection, the following options are available to configure: -
Send an email notification when a failure occurs - If you'd like to receive e-mail alerts for any cross-tenant synchronization errors relating to the provisioning capability, please provide an e-mail address, preferably a Distribution List or Shared Mailbox.
Prevent accidental deletion - If you'd like to prevent the accidental deletion / disabling of users within the inbound (destination) tenant, you can enable this setting and specify a deletion threshold. Any deletions above the configured threshold will require an administrator to approve the deletion request.
Scope - This setting defines who will be in scope for the cross-tenant synchronization provisioning activity. Options are either "Sync only assigned users and groups", which is the recommended configuration for both compliance and performance or "Sync all users and groups". When "Sync only assigned users and groups" is selected, the assigned users are defined within the "Users and groups" tab, detailed in the next section. An additional benefit of scoping provisioning to assigned objects only is the ability to pilot and control the roll-out.
Provisioning assignment
Tenant: Outbound (Source)
If the cross-tenant synchronization provisioning scope has been configured to "Sync only assigned users and groups", this section will be relevant in defining the assigned objects.
Access the "Users and groups" tab within the previously created cross-tenant synchronization configuration. This configuration can either be accessed through the cross-tenant synchronization blade or through the Enterprise applications blade. Once within the "Users and groups" tab, click the "Add user/group" subsection.
Within the "Add user/groups" window pane, search for the users and/or groups required for this stage of the provisioning and then put them in scope by adding them. In this example, we'll add a group called "Cross-tenant Sync Users", which contains two users, Mary and Fred.
Enable provisioning
Tenant: Outbound (Source)
Once all the necessary configuration has been completed for the provisioning service, it's time to enable the cross-tenant synchronization feature in its entirety.
Access the "Provisioning" tab within the previously created cross-tenant synchronization configuration. This configuration can either be accessed through the cross-tenant synchronization blade or through the Enterprise applications blade. Once within the "Provisioning" tab, locate the "Provisioning Status" setting, select "On", and then click "Save".
The cross-tenant synchronization service will commence shortly after, provisioning the in-scope objects in the inbound (destination) tenant.
Provisioning results
Tenant: Inbound (Destination)
With cross-tenant synchronization enabled, and after waiting for the initial provisioning job to complete, we can see that the users assigned in the Provisioning Assignment section have now been created within the inbound (destination) tenant. We can also observe the attribute mapping amendment we made to the Display Name attribute, with the addition of the "- TEST" suffix.
Reporting & Logs
The tasks and processes associated with the cross-tenant synchronization capability can be traced, reviewed, and monitored at the different stages of provisioning throughout each of the configured tenants.
Tenant: Outbound (Source)
Within the outbound (source) tenant and within the referenced enterprise application / cross-tenant synchronization configuration, there are two key tabs we can review logs: -
Provisioning Logs - Track activities performed by the provisioning service itself, such as the provisioning and synchronization of user objects and their attributes.
Audit Logs - Track activities concerned with the cross-tenant synchronization enterprise application, such as the updating of attribute mappings, the enabling or disabling of the provisioning service, or the assigning of users to the provisioning service.
Reviewing the Provisioning Logs first, two entries are initially visible per-user object, both within a similar timeframe. The first entry reflects the initial provisioning of a user object within the destination tenant, and the second entry reflects any configured attribute changes thereafter: -
Opening the second log entry for the user "Mary", presents further details about the provisioning activity for the in-scope user object. This is particularly useful when troubleshooting any synchronization errors, as well as reviewing the provisioning workflow and behaviour: -
Within the "Modified Properties" tab, we can observe any created and/or modified attributes. In this example, we can witness the custom attribute "extensionAttribute5" being established, being the same custom attribute we defined in an earlier step (Provisioning mappings & attributes): -
The "Troubleshooting & Recommendations" tab will aid in any synchronization errors, and the "Summary" tab is great for a quick overview of the provisioning cycle: -
Moving onto the Audit Logs next, there is an array of different entries for the various activities concerned with the management and configuration of the cross-tenant synchronization solution itself. In the example below, we've identified a few different management activities such as Enabling and starting the provisioning service, updating attribute mappings within the synchronization settings, and assigning an Entra ID Group to the solution, ensuring its members are in-scope: -
Opening one of the log entries presents further details about the management activity. This is particularly useful when troubleshooting or monitoring any changes to the configuration and solution itself, such as attribute or assignment changes, as well as the disabling of the provisioning service. In the example below, we can see that the Entra ID Group "Cross-tenant Sync Users" has been assigned the cross-tenant synchronization solution, thus putting its members in-scope for provisioning (as performed within the Provisioning assignment section): -
Tenant: Inbound (Destination)
Within the inbound (destination) tenant, we can leverage the Entra ID Audit Logs to monitor and trace the activities resulting from the cross-tenant synchronization provisioning service.
Tracing the activities associated with the user "Mary" within the destination tenant, we can track the various stages of user-object provisioning & creation, such as the addition of the user, the submission of the silent "invitation" to the external user, the updating of user attributes, and the silent redemption of the external user "invitation": -
Opening the "Add User" entry, we can observe the user "Mary" from the outbound (source) tenant being provisioned into the inbound (destination) tenant: -
Opening the "Update user" entry, we can observe the "- TEST" suffix being appended to the newly provisioned user object for the user "Mary" within the outbound (destination) tenant: -
Additionally, as users are being provisioned as members, we can also observe the newly provisioned objects being added to the default and dynamic "All Users" Entra ID Group: -
Use cases & examples
Now that we've taken an in-depth look into configuring, deploying, and monitoring the Cross-tenant Synchronization capability, let's review some of the potential use cases and business-case examples for adopting the feature.
Dynamic Group
First and foremost, once the in-scope users have been provisioned from the Outbound (source) tenant into the Inbound (destination) tenant, we can begin leveraging Dynamic Entra ID Groups within the destination tenant to target these user objects. These Dynamic Groups are particularly useful when granting access to various services hosted within the Inbound tenant, such as a SharePoint Online site or Enterprise Application, as well as when introducing controls around governance and compliance best practices.
In the example below, we will target the custom extension attribute "extensionAttribute5", which we configured in the previous section Provisioning mappings & attributes. This attribute has a value of "Three Sixty Thrive Test", being the name of the Subsidiary organisation in our predefined scenario.
By creating a dynamic membership rule for an Entra ID group, we can target the custom "extensionAttribute5" attribute by referencing the specific value we previously defined, being "Three Sixty Thrive Test". Going forward, any user object that has this attribute and value populated will automatically become a member of the associated group.
As illustrated below, the configured dynamic membership rule has detected the two provisioned user accounts from the Outbound (source) tenant, but as expected, has ignored an already existing and native Three Sixty Thrive user in the Inbound (destination) tenant as it does not have this attribute populated, primarily because it has not encountered the provisioning workflow whereby this attribute is populated.
The final and resulting group membership is clarified below.
SharePoint Online - Intranet
One useful business-case example would be to automatically grant the provisioned users from the outbound (source) tenant access to a SharePoint Online site hosted within the inbound (destination) tenant.
In the example below, the Three Sixty Thrive organisation has a corporate Intranet hosted in SharePoint Online which needs to be made accessible to users within the Three Sixty Thrive Test subsidiary. To facilitate this access, we will leverage the dynamic Entra ID group created previously. Here, we simply browse to the target SharePoint site and then opt to share it with the referenced dynamic Entra ID group with Read Only permissions.
As detailed in the following screenshot, the provisioned user from Three Sixty Thrive Test, called Mary, can now access the Intranet with read-only permissions.
Microsoft Teams - Team
Another collaboration-oriented example of a use-case is the ability to efficiently invite provisioned users into a Microsoft Team hosted within the inbound (destination) tenant.
In the example below, the Three Sixty Thrive organisation has a company-wide team called "Company Team" which needs to be made accessible to users within the Three Sixty Thrive Test subsidiary. To facilitate this access, we will leverage the dynamic Entra ID group created previously. Here, we simply browse to the target Microsoft Team and then opt to add the referenced dynamic Entra ID group.
Once added, the in-scope users, being the Three Sixty Thrive Test subsidiary users, will receive an e-mail notification shortly after, detailing that they have been added to the Microsoft Team.
Mary, a provisioned user from Three Sixty Thrive Test, can now access the Microsoft Team "Company Team".
Microsoft Teams - Instant Chat/Calls
Another example of a Teams use-case reflects the introduced ability to easily and seamlessly instant-message, call, and interact between users from both tenants; Three Sixty Thrive and Three Sixty Thrive Test.
As illustrated in the screenshot, a user from Three Sixty Thrive within the Inbound (destination) tenant, can efficiently search for and find provisioned users from the Outbound (source) tenant.
In the example below, a user from Three Sixty Thrive has messaged a provisioned user from Three Sixty Thrive Test called Mary. The perspective in the following screenshot is viewing Teams from Mary's account.
Line of Business Applications
Moving on from SharePoint and Teams, granting provisioned users access to line-of-business applications, such as SAAS applications, integrated Enterprise Applications, and Azure Application Proxy applications, hosted in the inbound (destination) tenant is a fantastic example of another useful business case.
In the example below, the Three Sixty Thrive organisation has an internal application called "Company App", hosted on-premises which is published via Azure Application Proxy. Three Sixty Thrive would like users from the Three Sixty Thrive Test to have access to this same application.
To facilitate this access, we first need to locate and open the associated Enterprise Application for the Azure Application Proxy instance, as illustrated below.
Within the Enterprise Application, we'll modify the "Users and groups" assignment settings to reflect the same Entra ID dynamic group created previously, which automatically includes provisioned users from the Three Sixty Thrive Test tenant.
Once the assignment settings have been adjusted accordingly, a user called "Mary" from Three Sixty Thrive Test, who was previously provisioned into the Three Sixty Thrive tenant, can now login to the myapps.microsoft.com portal and switch organization to Three Sixty Thrive.
Within the Three Sixty Thrive organisation, Mary can now see and access the published "Company App" application hosted within the Inbound (destination) enviornment.
Exchange Online - Address List
Another welcomed feature is the introduction of provisioned users to the Global Address List within the Inbound (destination) tenant's Exchange Online instance. One obvious benefit to this feature is the ability to seamlessly search for and discover contact details for recipients who officially reside within the outbound (source) tenant. An added benefit is that these recipients will be dynamically updated, as their attributes will be reviewed and revised as per the routine provisioning cycles and attribute mapping configurations defined in the Outbound (source) tenant. This latter point introduces a notable improvement upon static mail-contact entries which would usually need to be updated manually as and when changes occur.
Exchange Online - Distribution List
One further Exchange Online use case is the ability to include provisioned user objects and recipients into Distribution Lists, such as the "All Company" list detailed below. One obvious benefit to this feature is the ability to seamlessly include recipients from the outbound (source) tenant into destitution lists hosted within the inbound (destination) tenant. Again, an added benefit is that these recipients will be dynamically updated, as their attributes will be reviewed and revised as per the routine provisioning cycles and attribute mapping configurations defined in the Outbound (source) tenant. This latter point introduces a notable improvement upon static mail-contact entries which would usually need to be updated manually as and when changes occur.
In the example below, a user from the Three Sixty Thrive organisation sends an e-mail to the "All Company" distribution list, which now includes the provisioned users from Three Sixty Thrive Test.
As per the following illustration, a user called "Mary" from Three Sixty Thrive Test has received the e-mail sent above, as the recipient has been successfully provisioned into the Three Sixty Thrive tenant and added to the Distribution List in question.
- Thanks for reading, and Happy Cross-Tenant Synchronizing!
Comments