I know many technology organisations, tend to run or at least interact with multiple Azure tenants to meet their business needs — whether to meet a particular compliance requirement or to collaborate with other businesses. This article covers a great new feature that Microsoft has recently become Generally Available — 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.
Recently Microsoft announced a new Generally Available 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.
So what does “Cross Tenant Access” allow me to do?
In a nutshell, it allows for fine grained control of 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!).
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 over to Azure Active Directory > External Identities > Cross-tenant access settings.
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 modify which users, groups and applications can collaborate 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 user’s “home” tenant has MFA enabled and has 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 an 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 their organisation sanctions. Or in multi tenant scenarios even managed by your own organisation.