Using Cross-Tenant Access Settings for Azure B2B Collaboration

New Way to Control Inbound and Outbound Guest Access

When I wrote about configuring the settings for cross-tenant access policies, I focused on Azure B2B Direct Connect, the mechanism used by Teams shared channels to support external members. At the time, I didn’t cover Azure AD B2B Collaboration, which is how guest accounts join a host organization and become members of Teams and Microsoft 365 groups and gain access to SharePoint Online resources. Azure AD B2B Collaboration has been available since 2016, and it’s a very popular and well-understood capability at this point.

Essential capabilities like Azure B2B Collaboration sometimes come with downsides. Apart from the potential for proliferation of guest accounts which require review and removal on an ongoing basis, administrators have had no way to control how members of their organization access resources in other tenants.

Azure AD B2B Collaboration External Settings

Blocks are available for incoming guest access through either a whitelist or blacklist imposed by Azure AD external collaboration settings (Figure 1), but the same type of block is unavailable for stopping tenant users having guest accounts hosted by external organizations. Applying a block to stop people adding guests from a domain doesn’t remove existing guest accounts from that domain. If you want to do this, you’ll need to scan group membership to find and remove problem accounts.

Applications depend on Azure AD to apply the blacklist. If you try to add a new guest user from a blocked domain to a team membership, you’ll see the error shown in Figure 2. Teams is happy to accept the email address for the new guest and attempt to update the membership of the underlying Azure AD group. It’s at this point that Azure AD detects that the new group member comes from a prohibited domain and signals the error to Teams.

Cross Tenant Access is the New Strategy

Going forward, Microsoft intends that the external collaboration settings should control access from consumer domains like Google.com and Yahoo.com, while access from other Microsoft 365 (or Azure AD) organizations should come under the control of cross-tenant access.

Although you can continue to use external collaboration settings to block the creation of guest accounts homed in Microsoft 365 organizations, cross-tenant access offers control over both inbound and outbound settings for individual domains down to a granular level to permit access on a per-group, per-user, or per-application basis. In short, cross-tenant access is more capable and functional than external collaboration settings.

Updating Azure B2B Collaboration Cross Tenant Access Settings

It’s important to remember that cross-tenant access is still a preview feature. I suspect that Microsoft put cross-tenant access into preview to support the public preview of Teams shared channels. As a preview feature, not everything works as it will when Microsoft makes the feature generally available.

Microsoft documentation is available to explain how to manage cross-tenant access settings for B2B Collaboration. Manipulating these settings works as it does for B2B Direct Connect. For instance, I decided to impose a control on users from the O365Maestro tenant so that only certain people from that tenant could have guest accounts in my organization. I created a security group in the O365Maestro tenant and populated it with users. I then added the identifier (GUID) for the group to the inbound settings for O365Maestro as shown in Figure 3.

After saving the policy, I couldn’t work out why the new settings appeared ineffective. New settings are effective immediately, but I could still add new guest accounts not in the approved group to group memberships using OWA and Teams. The Microsoft invitation service issued email notifications to new guests (Figure 4), which is slightly confusing for people whom you intend to block.

Unlike how Azure AD imposes external collaboration settings when group/team owners attempt to add new guests, cross-tenant access settings allow the creation of guest accounts and the addition of these accounts to group ownership. We can see this by checking the group membership with PowerShell:

$GroupId = (Get-MgGroup -Filter "displayName eq 'Office 365 Adoption'").Id
Get-MgGroupMember -GroupId $GroupId -All | ForEach {Get-MgUser -UserId $_.Id} | Format-Table DisplayName, Id, mail

DisplayName                 Id                                   Mail
-----------                 --                                   ----
Tony Redmond                eff4cd58-1bb8-4899-94de-795f656b4a18 Tony.Redmond@
Ben Owens (DCPG)            a3eeaea5-409f-4b89-b039-1bb68276e97d Ben.Owens@
Ben James                   96bfb216-e88c-4f1f-86d7-04747e5fc686 Ben.James@
Chris Bishop                a221d10f-e0cf-4a1d-b6a2-4e844670f118 Chris.Bishop@
Tricia Griffin (Champion)   d1e4e149-ea8c-40c5-b386-6610c650695b tricia.griffin@o365maestro.onmicrosoft.com

Taken together with membership notifications issued to new guests, it’s easy to see how administrators might become confused about how cross-tenant access works, especially as there’s no mention of how Azure manages the blocking of connections in Microsoft’s documentation. When I raised these concerns to the Azure AD developers, they acknowledged that improvements are needed and said that they are working to better align external collaboration and cross-tenant settings to remove areas of friction like the dispatch of notifications. No timeline is available for when these improvements might be available.

A Better Connection Block

Then the penny dropped. Cross-tenant access blocks do work, but only when users barred by policy attempt to connect. At this point, Azure AD evaluates the cross-tenant access settings and imposes the block (Figure 5) to stop anyone barred by policy from accessing the tenant.

The net takeaway is that external collaboration and cross-tenant access use different mechanisms to control guest accounts. The change is logical when you think about it. Blocking inbound guest accounts when Azure AD evaluates inbound authentication is a more effective way of controlling access. Sure, new guest accounts might end up in group membership, but they won’t be able to connect. And best of all, guest accounts from blocked domains which already exist in teams and groups won’t be able to connect either, so there’s no need to find and remove these accounts. Unless you want to!

Checking Sign-In Logs for Blocked Azure AD B2B Collaboration

Azure AD captures the same information in the sign-in audit log (Figure 6), meaning that administrators can assess the effectiveness of the blocks imposed by cross-tenant access.

To check for failed cross-tenant access connections with PowerShell, use the same approach explained in this article to analyze Teams shared channel connections and change the command to find sign in records for Azure B2B Collaboration instead of Azure B2B Direct Connect. Here’s what I used:

[array]$AzureADSignIns = Get-MgAuditLogSignIn -Filter "ResourceTenantId eq '$TenantID' and CrossTenantAccessType eq 'b2bcollaboration'" -All

After the report is generated, it contains all records for the tenant for inbound guest accounts which access tenant resources. To isolate the connections blocked by the cross-tenant access settings, we filter to find the records with status code 500213:

$Report | ? {$_.ErrorCode -eq 500213}

Timestamp     : 08/04/2022 15:40:32
User          : Tricia Griffin (Champion)
UserId        : d1e4e149-ea8c-40c5-b386-6610c650695b
UPN           : tricia.griffin@o365maestro.onmicrosoft.com
TenantName    : Office 365 for IT Pros
TenantId      : a662313f-14fc-43a2-9a7a-d2e27f4f3478
Resource      :
AppName       : Microsoft Teams Web Client
Type          : b2bCollaboration
ErrorCode     : 500213
FailureReason : The resource tenant's cross-tenant access policy does not allow this user to access this tenant.

Azure AD B2B Collaboration and SharePoint Sharing

Apart from guest user access to Teams and Groups, SharePoint Online uses guest accounts when B2B collaboration is integrated with SharePoint Online and OneDrive for Business. In this scenario, Azure AD creates guest accounts when users share document and folders with external people. The guest accounts are subject to the external collaboration settings. For instance, if I try to share a document with a Gmail user, SharePoint detects that the destination is on the blacklist and issue the error (Figure 7):

“Sorry, we’re unable to reach the server right now. Please try again later.”

Presumably the error occurs when SharePoint attempts to create the sharing link and realizes that the recipient comes from a blocked domain. In terms of user comprehension, the error is a little odd and doesn’t tell the sharer what they’re doing wrong, but at least SharePoint stops users sharing documents with external people when the organization blocks domains.

Currently, SharePoint Online and OneDrive for Business do not stop users sending sharing links to external people blocked by cross-tenant settings, but the recipients of the sharing links cannot authenticate and gain access to content. This is the right thing to do, but it could confuse users, so hopefully Microsoft will consider improving the flow here too.

New Flexibility in Outbound and Inbound Controls

The introduction of cross-tenant access controls for both Azure AD B2B Collaboration and Azure AD Direct Connect gives administrators more flexibility over how they allow inbound and outbound sharing to happen. As always, it’s best to start with a simple implementation and introduce complexity as you, your users, and Microsoft applications get accustomed to the new controls.