Run Multiple Azure Tenants?

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.

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!).

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:

1. Inbound — Affecting users coming into your tenant.
2. 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:

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.

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.

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 great use cases next…

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.

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 a 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.

In this use case, you are part of company “Y” which has one corporate AAD Tenant 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 ensure 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 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.