Run Multiple Azure Tenants? This new cross-tenant feature is for you!
I know many technology organisations, tend to run or at least interact with multiple Azure tenants to meet their business needs — wether this is to meet a particular compliance requirement or to collaborate with other businesses. This article covers a brilliant new feature that Microsoft has recently entered into Public Preview — Cross Tenant Access Settings.
One of the main reasons I count Azure as my preferred Cloud Platform, is Azure Active Directory (AAD) — the identity core of the Microsoft ecosystem. The power AAD brings to securely manage identities and collaborate with both businesses and consumers out of the box is truly mind blowing.
This post will assume you are familiar with AAD B2B collaboration — if not check out the references in the related articles at the bottom of the page.
On 8th Feb 2022 Microsoft announced a new public preview feature “Cross Tenant Access” — which in my opinion greatly compliments both the Business to Business (B2B) functionality and will also really help if you (like me) manage multiple Azure tenants.
You can see the full documentation below:
So what does “Cross Tenant Access” allow me to do?
In a nutshell it allows for fine grained control on the interaction between different Azure Tenants. I’m sure there are plenty of use cases however i’ll focus the article on two great use cases based on my past experience.
The first use case focuses on trusting MFA claims from a users home tenant — keeping things secure but increasing user experience by not having them have to complete multiple MFA prompts each authentication.
Secondly we will discuss trusting Compliant device claims across multiple organisations. This will allow businesses to ensure their tenants are only accessed by managed devices — allowing the home tenant to do all of the legwork here, this is great to ensure cloud administration stays on compliant devices that your organisation has sight of.
Both of the above use cases talk about the inbound “trust” part of the offering, and this article will not go into too much detail around controlling users, groups and apps interactions between tenants (which may well be a sweet use case for collaboration focused businesses!).
Caution — It’s worth mentioning that as of writing this feature is still in Public Preview so use with care within your organisations, there may be some edge cases not yet covered… however it’s super easy to set up for some testing & proof of concepts!!
Lets do this… Setting it up
The beauty of this feature is it requires no changes to existing conditional access policies meaning that from an access control perspective, your tenants posture remains largely the same.
Head on over to Azure Active Directory > External Identities > Cross-tenant access settings (Preview).
You’ll see straight away that you can either configure this for:
Specific Organisations- In order to do this — click Add Organisation, and you’ll need to know either the tenant id (GUID) or one of the domain names associated with the external Azure Active Directory — see below with an aptly named tenant “test.onmicrosoft.com”.
Default Settings — modifying these will apply to all tenant collaborations — so use with caution.
The settings themselves are split into two groupings:
- Inbound — Affecting users coming into your tenant.
- Outbound — Affecting member users in your tenant trying to collaborate within other Azure AD Organisations.
You can then either modify which users, groups and applications can collaborate both inbound and outbound. Top Tip: You’ll need access to any external organisations so you can fetch the unique GUID associated with any groups / applications.
Within the inbound grouping you can modify the inbound trust settings — which we will focus the rest of the article on:
Trust MFA from Azure Tenants
If a users “home” tenant has MFA enabled and they have already completed an MFA challenge as part of their initial authentication. This will be trusted on entry to your tenant and users will not have to re-do a MFA challenge in the resource tenant.
Trust Compliant Devices
If your organisation uses Intune to manage devices it can trust these claims. This means you can ensure a B2B guest user is using a device that is sanctioned by their organisation. Or in multi tenant scenarios even managed by your own organisation.
Trust Hybrid Azure AD Joined Devices
This use case suits primarily windows devices that are joined to a Hybrid AD (ie an Azure AD synced with a traditional domain controller). Essentially another way of ensuring that the user is accessing from a governed device.
Let’s focus on these trust settings with the key use cases next…
The Key Use Cases
In order to take advantage of these use cases your tenant must already have conditional access configured for either MFA or managed device checks — I will drop an article on these at the end of the post.
1) Stopping the need for multiple MFA challenges between tenants
Let’s imagine you are collaborating with Company “D” and they are accessing some PowerBI Reports that you are publishing from your “home” Azure Tenant. For security best practice you have quite rightly enforced MFA on your tenant using Conditional Access but from a user perspective this means maintaining two different MFA challenges (one per tenant). This is not only confusing to the average user but can cause issues if users lose or change their authentication device — which will become an overhead to your support desk.
Worry no longer — enabling the trust of MFA tokens means users originating from a trusted tenant will only be challenged for MFA once, see snippet of activity logs below showing the claim has already been satisfied within the token.
Should the claim not be satisfied for whatever reason, your conditional access will simply fall back to enforcing MFA.
2) Linking Multiple Tenants to one trusted Hybrid AD for Management / Compliance
In this use case you are part of company “Y” who has one corporate AAD Tenant which is responsible for device management using Intune. However the company maintains multiple Azure Tenants due to acquisitions, or other segregated / specific use cases. You want to make sure that the other Azure tenants are only administered from known and compliant devices registered within your “home” corporate AAD Tenant. This is a common security requirement to help tackle device vulnerability management and common data exfiltration concerns.
Now this is possible — set up a conditional access policy that checks for compliant managed devices within each resource tenant and then establish a trust policy with your corporate AAD tenant on “Trust Compliant Devices”. It’s recommended to do this in “Report Only” mode in order to test this out but you will see the following within the sign in logs for your resource tenant.
This means you can start to block privileged operations and applications unless they originate from a trusted device from your “home” tenant.
Wrapping Up — Kudos to Microsoft !
In my opinion this feature really packs a punch for users who support multiple Azure tenants or frequently collaborate with others via the use of Azure B2B collaboration. I’m looking forward to this feature reaching General Availability, hopefully within the next couple of months. Let me know what you think in the comments below!
