With the release of Azure AD cross-tenant access settings, I’ve noted some confusion among folks as to what it is, and as importantly, what it isn’t.
I’ll also be covering B2B Direct Connect, because even though it’s a separate feature, with release coinciding at the same time as cross-tenant access settings, I see it all being lumped “into the same” set of preview features.
The Microsoft Docs article on this is an excellent source of information, which can be found here, Cross-tenant access overview – Azure AD | Microsoft Docs. Along with that, we’ll dive into the background and use cases for this new suite of knobs and dials for our external identities.
Cross-tenant access settings and B2B direct connect are currently in Public Preview.
Terminology
Guest – For clarity, when speaking about guest users for the context of this post, we are talking about users invited into your Azure AD tenant.
Resource Azure AD Tenant [Resource Tenant] – If you are inviting guests into your Azure AD tenant, your tenant is the resource tenant. It represents your organization. If you are a guest, then the resource tenant is the tenant you have been invited into.
Home Azure AD Tenant [Home Tenant] – This is the tenant where the user objects live. If your user object exists in your organizations Azure AD tenant, your tenant is both the home tenant and resource tenant – your users and applications all “live” in the same place. Guests into your tenant will have a different home tenant.
What it is not
Before getting into what we can do with cross-tenant access settings, let’s cover what this is not (at least at the time of this writing).
Parity to an Active Directory trust
Cross-tenant access settings may invoke a feeling of configuring a trust in Active Directory, which many Microsoft identity practitioners may be familiar with.
It is closer to the opposite of a trust, in the sense that by default Active Directory has no implicit trusts and you must explicitly configure trusts. Azure AD historically is opposite, any organization, unless settings are adjusted, can invite users from any Azure AD tenant into the organization. These settings allow us to be more granular in how we restrict guest access inbound and outbound to our Azure AD tenant.
Further, when we examine B2B Direct Connect, we realize that the only use case, currently, is Teams shared channels.
When we think of an Active Directory trust, we think of the fact that user objects only exist in the source user forest. With cross-tenant access settings, and the limitations with B2B Direct Connect, we still must invite user objects into our resource tenant – all the other “things” tied to our Azure AD tenant need the objectID within our resource tenant to reference.
What it is
A mechanism to provide granular B2B guest control
When speaking about B2B guests and external identities, many organizations tend to focus on the aspect of guests being invited into their tenant. There is the other side to that B2B coin, which is restricting what organizations you may want your users to have access to.
Certain organizations, especially those in the regulated industries, have concern over which external tenants their users can connect to. Up until now, organizations would need to apply tenant restrictions, Use tenant restrictions to manage access to SaaS apps – Azure AD | Microsoft Docs, which has a higher level of complexity to it – the implementation requires a proxy to perform traffic inspection and HTTP header insertion.
Now, organizations that have strict requirements regarding outbound guest access can, by default, restrict outbound access, and then create a more granular allow list.
We also now can be granular down to user/group level of who can access certain organizations. Say you want to only allow employees from payroll to be able to access the tenant the vendor uses and restrict outbound access to everyone else – now you can do that.
Likewise, there is granularity on the inbound side. Say you are that vendor that processes an organizations payroll and want to ensure that only the known users for the company you serve can come into your organization. You can restrict inbound as well, limiting what guests are allowed in.
A way to trust external MFA and Device Compliance
Many organizations that are familiar with conditional access and guest policies have encountered the need to enroll in Azure AD MFA twice or more – once for their home tenant and once in every other resource tenant they access. This experience, from a user perspective, is less than ideal.
With cross-tenant access settings, we can now choose to trust MFA from the guest users home tenant. We also can be granular – if we want to trust MFA from certain tenants, but require MFA enrollment from others, we can do that.
More interestingly, we can now trust device compliance and hybrid join status, from the guest home tenant. While I still have certain reservations about the quality of relying on hybrid join alone, focusing on device compliance, it really opens a lot of cross-tenant collaboration, and brings an innovative approach to leveraging Zero Trust modeling when working with guests. While this still has the requirement that the guest home tenant must be leveraging Intune or a 3rd party MDM that can report in device compliance, it makes this a possibility.
In my own testing, I was able to leverage device compliance in conditional access for a device in a guest tenant and it worked with ease.
A few lingering questions
Where is Conditional Access processed?
This hasn’t changed with the new cross-tenant access settings, but it’s a good time to review.
Conditional access is always evaluated in the resource tenant.
The resource tenant needs to ensure that their Conditional Access policies meet the needs of protecting their applications.
Likewise, the home tenant cannot restrict outbound access to another tenant with Conditional Access. Because the guest is not accessing resources in their tenant, even an all applications block CA policy will not prevent the user from accessing a resource tenant as a guest – which really brings us back to what these new settings solve.
Where is Identity Protection processed?
User risk is evaluated in the home tenant, and sign-in risk is evaluated in the resource tenant for B2B users. When firing up Tor, and accessing O365 with a guest, my test user was blocked by Identity Protection in the home tenant because it was flagged as a high user risk. So depending on the sort of threat detected by Identity Protection, you may find users being restricted by both the home and resource tenant when Identity Protection is in play.
The details on this are further elaborated on in the Microsoft Docs article, Identity Protection and B2B users – Azure Active Directory | Microsoft Docs.
One new trick – out of a possible many
PIM in the home tenant for outbound guest access
The ability to apply PIM to guest user accounts is not new. But if we combine the preview feature of PIM for group membership, and apply outbound restrictions to a certain group, the home tenant can build a request process for outbound access.
In that this is quite restrictive, I would see a narrow range of use cases, as it really hampers collaboration between tenants. For those organizations who previously completely turned off the ability to collaborate with other organizations due to things like data sensitivity, the door might now be opened a bit.
Final Notes
External Identities and B2B are continually evolving. While there is still a large gap to bridge for many situations, this definitely is bringing us one step closer. B2B Direct Access in particular will be interesting to see how Microsoft evolves it – will it come closer to how an AD trust operates, or will there be improvements on how guests are invited into tenants.
As usual, any questions/concerns/comments please reach out to me, and if you find any new unique use cases for cross-tenant access settings, would love to hear them.
About this posts featured image
The chosen photo is the work of charleseluvio, used under the Unsplash license.
Given the nature of B2B, imagery of a handshake seems like a natural fit. Instead of an image though of an actual handshake, I decided that the neon sign, being electric, feels closer to two computing systems connecting, as well as it leaves the viewers imagination more open as far as what those two hands might look like, both as people but also as businesses connecting.
