Blog Post

Microsoft Entra Blog
4 MIN READ

Collaborate more securely with new cross-tenant access settings

Robin Goldstein's avatar
Robin Goldstein
Former Employee
Feb 07, 2022

Hello friends, 

 

As a follow-on to our previous External Identities update, today I'm really excited to announce the availability of cross-tenant access settings for external collaboration in public preview. 

 

Cross-tenant access settings enable you to control how users in your organization collaborate with members of external Azure AD organizations. Now you’ll have granular inbound and outbound access control settings that work on a per org, user, group, and application basis. These settings also make it possible for you to trust security claims from external Azure AD organizations like Multi-Factor Authentication (MFA), device compliance, and hybrid Azure AD joined devices. 

 

When it comes to external collaboration, you’ve told us that:  

 

  1. You want to ensure only approved external users can access your apps and resources, and only approved users from your organization can access external apps and resources.  
  2. You want to trust MFA claims from your partners, so your guest users who have performed MFA in their directories aren't prompted for MFA again in your directory. 
  3. You want insights on what apps your users are accessing externally and what apps external users are accessing in your organization. 

 

So, we’ve designed the experience based directly on your feedback. Let’s take a look at how it works. 

 

How to get started with cross-tenant access settings  

 

Control the external users and organizations that can collaborate with your users 

Inbound settings let you control which external users can access your apps and resources. You can allow all external users to collaborate with you, or you can limit access to only allow specific users and groups from specific organizations. You can also specify the apps in your organization you want these users to be able to access.  Read the documentation to learn more about cross-tenant access settings. 

 

 

Control the external organizations your users can collaborate with 

Outbound settings let you control which external organizations your users can collaborate with. You can allow your users to collaborate with all external organizations or only allow specific users and groups to access specific apps in specific external organizations. 

 

 

Trust security claims from external Azure AD organizations for MFA and device  

Inbound trust settings let you trust the MFA external users perform in their home directories. This addresses the feedback you’ve given us around your external users having to perform MFA multiple times, both in their home directories and in your directory. Now you can enable a seamless authentication experience for your external users by trusting the MFA they perform in their home directories so they don’t need to complete MFA with you. You’ll also save on the MFA costs incurred by your organization.  

 

Inbound trust settings also let you trust devices that are compliant, or hybrid Azure AD joined in their home directories. Previously, you were not able to enforce device-based Conditional Access policies such as requiring compliant devices or hybrid Azure AD joined devices for external users. Using inbound trust settings to accept device claims from external Azure AD organizations, you can now protect access to your apps and resources by requiring that external users use compliant, or hybrid Azure AD joined devicesLearn how inbound trust settings work with Conditional Access. 

 

 


Know who’s accessing your organization’s resources 

Through the sign-in logs, you can see which external apps your users are accessing, as well as the external users who are accessing your resources. Learn more in the documentation. 

 

 

 

Start by evaluating how you collaborate 

 

Before you customize cross-tenant access settings, it’s important to understand which external organizations need access to your apps and resources and which of your users need to access external apps and resources so that you don’t inadvertently block ongoing collaboration. We recommend that you use this workbook to understand how your organization is collaborating with external organizations to avoid any business interruption. 

 

What customers are saying 

 

Bupa is an international health insurance and healthcare group with over 31 million customers worldwide. As they have been testing this feature, they’ve said:  

 

"This feature lays the bedrock for increased collaboration and most importantly security for our large and complex organization." 

 

In addition, we have enabled customers in the most regulated industries to open collaboration for the first time and recently received this feedback:  

 

“Cross-tenant access settings will help us greatly reduce risks, increase security, and enable us to better support our business in external tenant access and collaboration needs. Happy security department, happy business, and importantly happy auditors and regulators." 

 

We love hearing from you, so share your feedback on these new features through the Azure forum or by tagging @AzureAD on Twitter. 

 

Robin Goldstein  

Twitter: @RobinGo_MS 

 

 

Learn more about Microsoft identity: 

Updated Feb 07, 2022
Version 1.0

49 Comments

  • SocInABox's avatar
    SocInABox
    Iron Contributor

    Are there any negatives for using this over Azure Lighthouse if all you need from Lighthouse is identity management and not other resource management?

  • Do we have an estimation date for this feature to be ready for production? I think is super interesting 😍

  • AnthonyEY's avatar
    AnthonyEY
    Copper Contributor

    Hey, Robin Goldstein - this could be a little misleading.  Cross cloud typically means a user in a commercial tenant accessing a resource in a sovereign cloud (21v or GCC High), and vice versa.  This article makes no reference to sovereign tenants so im assuming the scenarios outlined here are really directed at users in a commercial tenant accessing resources in a separate commercial tenant?

     

    Can you clarify please?

    Thanks.

  • Kjetil Smith's avatar
    Kjetil Smith
    Bronze Contributor

    Kind of small step in the right direction, but I would love if the identity team could even add more of the external identities, the part we have been using in Azure B2C our identity playground. I love the possibilities where tenant and the identity owner could have even more control. In B2C you can easy require through different Conditinal Access principles such as different elevation through different MFA factors; even yet another ID(entity)P(rovider) as a yet another MFA factor or even control the MFA handling OnPrem or in a different cloud. You can in B2C inspect and see if the external IDP or in the case above (multitenant tenant authentication) if the user has gone through the required way to identify the user (through different MFA factors) in a different tenant, if not do require a specific or some other MFA factor in the B2C tenant. In B2C we can also consider different groups or roles to pass through or transform to different authorization concepts, also different rule set to different Azure tenants and of course the ability to restrict different tenants. A very nice feature in B2C is also the possibility to have One Cloud identity to multiple identities belonging to different IDP’s. This makes it easy to migrate to a another and different IDP and make it also possible to use a federated IDP as yet another MFA factor. 

     

    To my friends in the identity team I have described a concept of A(zure)(External)I(dentity)G(ateway) where we not only are using the CAE concepts, but more wisely also use the whole benefit of Azure Sentinel to be a more active part adding possibilities through AI and more dynamic protect customers tenants, systems and solutions in a far more secure and active way: that’s the future of Z(ero)T(rust)A(rchitecture) and why we control (C)IAM concepts from the Azure Cloud.

    Regarding the post bellow, I did also ask another friend of mine Vittorio when he was in the MS identity team the possibility to get some more info about the different tenants, sort of a lookup or the ability to do a callback; where the other tenant owner could accept or not to expose some human readable information on the tenant e.g. the tenant name; to the caller also dependent on callers tenant id. 

    It should be possible to use a lot more of the benefits we are using in B2C with Custom Policies also in the main tenant, not everywhere but at least in the different E(neterprice)App(lication)s. Some years ago, a friend of mine said this is something the office team will not allow and my replay just wait and see; the office team will love it when they know the benefits with those concepts and will take it even further. My dream is still One True Strong Identity in the clouds and if anyone is concerned with the ability to apply different licenses or other ways to control different features; they will have a lot more options. Customers are tenants in the clouds and would be even more satisfied customers if they can use more beneficial features. Just yet another reason why the customer will not be considering a different Cloud provider in the future or why new customers will choose the Azure Cloud or be part of their multi-Cloud strategy.

    BTW:

    As we have shown Azure External Identities can be used in Azure, different clouds and/or OnPrem where the tenant owner no longer have to steer on belfies, assumptions, feelings and their past, but on actual events and observations giving also the customers better insights on their future directions, development and investments. When the customers are in the clouds there’s a lot more and far better options to build secure and reliable systems. Another dream would be that Sentinel was just part of the Azure platform; just as Azure AD, making if far easier for customers to stay secure in the clouds.

     

    Best regards

    MrSmith

  • NicolasHon's avatar
    NicolasHon
    Brass Contributor

    Robin Goldstein 

    Nice post and upcoming features. 🙂

    One point that is always complicated is that a tenant is always displayed with an ID and nobody nether know what is what...

    If a user access an external tenant, we will see an ID in logs and the user will see a name for the tenant in his client applications. By this way, we have no chance to make corresponding things and perform a consistent analysis. How can I say to my user: "Hey you access Xyz.com company with Teams and we will change that behavior soon!"?

    In the other hand, when an external tenant access my tenant I also see an ID and the only way to find who could be owner of the tenant is to deal with email addresses that could give me an information.

    I think that the information of the admin contact and organization name of tenants need to be displayed, linked to the tenant ID, in logs.

    Do you think that there is a way to achieve that?

  • joeyvldn Great question!  One of the most frequent pieces of feedback we got from existing customers who enable B2B collaboration is that they wanted to minimize friction while still enabling secure collaboration. So if an organization I trust, say my main customer or supplier, has MFA policies for users who authenticate in their tenant, then I'm OK not asking that user to register for MFA in my tenant. It's a better user experience and less error prone.  However, not all customers will have that level of trust with other organizations and tenants, that's why the policy is configurable.

  • Brogie's avatar
    Brogie
    Brass Contributor

    Resource tenants within the same organization its useful, cuts down on the overhead of subscribing another MFA.

  • joeyvldn's avatar
    joeyvldn
    Brass Contributor

    I don’t get it. Why would u enable this

     

    “Trust security claims from external Azure AD organizations for MFA” ?

     

    sounds like the complete opposite of Zero Trust. And we never know how the trusted AAD organization verified their identity.