Microsoft recently released something that we consider one of the major updates to Azure AD B2B management in years: “Cross-tenant access settings (preview)”. This brand-new feature is allowed to be consumed under the current MAU (monthly active users) licensing of Azure AD External Identities. You will need at least an Azure AD tenant that is linked to a subscription. An Azure AD Premium 1 or 2 license is required. The first 50.000 unique guest users are free each month.

Before we dive in the details of this new feature, let’s have a quick look on what Azure AD B2B does today.

Microsoft has established default federation trusts between all Azure AD tenants as well as with Microsoft accounts (live, Hotmail, etc.). Now, this doesn’t mean that users of one tenant automatically gain access to another tenant: this is still fully under control of the owner of an Azure AD tenant.

In addition, Microsoft provides the capability in Azure AD to add Google and Facebook as a trusted identity providers (again, something you control yourself) or with any type of 3^rd party identity provider that supports SAML and/or WS-Federation.

To add a user from another identity provider (other Azure AD tenant, google, Hotmail, etc), you must add them as “guest”. This can be done explicitly using the Azure AD portal or implicitly if a user invites an external user (aka guest) to a teams-site or shares a document or folder with the user. For companies that want to have both flexible and secure governance of their external/guest users, we strongly recommend using Entitlement Management, that has been described in one of our previous webinars. From a security and authentication perspective, it is important to note that – by adding the guest user to your tenant – you implicitly trust the admins of the origin tenant as well as their primary authentication method! Using conditional access rules in your tenant, you can still control the secondary authentication method (MFA), but more on that later.

 

One of the features of this new “cross-tenant access settings” capability, is to control for which tenants you want to allow inbound access to your tenant: you can restrict that only guests from specific tenants are allowed (whitelist) or must be blocked (blacklist). This feature is already available using collaboration restrictions.

An entirely new feature is now that you cannot only control inbound access, but also outbound!

 

How do these outbound controls work?

Until now, you had no control whatsoever (unless some obscure mechanisms on network level, called tenant restrictions) to control which other tenants your users could access as guest. You are unfortunately even not able to see which user has access in other tenants. For most organizations, this is not a big issue, but if you are really concerned about data-leakage prevention, you might want to make sure that your users cannot copy your sensitive data to other the SharePoint or teams-site of another organization. With the new outbound collaboration settings, you can now control which users can access which other tenants in a granular way.

Note that this does not allow you to block users that have an account in another tenant, from accessing this tenant … it only allows you to control that your users cannot become a guest user in specific (or all) other tenants.

But wait, that is not it yet! One of the most interesting features, is that you now have more granular control over the conditions under which you want to trust users from another tenant.

To clarify this, I need first to dive briefly into Conditional Access rules.

With conditional access in Azure AD, you can control under which conditions users have access to applications or even specific Teams/SharePoint sites in your tenant. Examples:

• Users can only access your O365 applications from a personal device after multi-factor authentication and will be restricted to browser-only access

or

• Users can only access your O365 applications from a “trusted device”, whereby “trusted device” might imply that the device is managed by your organization using Intune and has been checked against your compliance policies.

or

• Admins can only access your tenant from a trusted device and from a trusted location and must re-authenticate at least once per day using MFA.

 

One inherent problem for guest users is that you had until now only very limited ways to control what conditions are applied for guest users: these users won’t have a trusted device from your organization’s point of view (since you don’t manage that device), they would need to register MFA and authenticate again with an MFA method managed in your tenant, etc. Net result is that guest-users have less controlled/restricted access to your data, than your own users!

With the new features in the “Cross-tenant access settings (preview)”, you can now control that for specific tenant, you DO trust their devices, if they are trusted in their own environment (Compliant in Intune or hybrid joined in their internal Active Directory). In addition, you can choose to trust their MFA own methods, so these guests’ users do not have to re-authenticate with another MFA method again when accessing your tenant.

Which new scenarios can I now support using these new features?

Well, there are quite some new scenarios that you can manage better … and especially manage more securely than before:

• Access from your production tenant to development or acceptance tenants, without having the re-create users (just invite users as guest from your production tenant), while still maintaining the same level of security by requiring MFA and compliant device
• Support multi-tenant setups more securely, e.g., in merger & acquisition situations, so this will allow you to maintain the same level of security across all tenants and when collaborating between tenants
• Have better control over data-leakage by restricting outbound access to other tenants as guest.
• Control Third-party Remote Access scenarios, for example allow an external IT partner to manage your environment securely, whereby you would only allow access for the personnel of the IT Partner if they were working from a device that is managed by the IT-partner itself and not from a personal device.

 

Stay tuned for further updates on this exciting new feature and follow us on LinkedIn to get the latest information on blogs, webinars or vlogs on this topic!