Improvements to Cross-Tenant Access Settings Based on Customer Feedback

Microsoft launched Azure AD (Entra ID) cross-tenant access settings in February 2022 to support the introduction of Teams shared channels. The new mechanism established a way for tenants to trust each other and created the basis for sharing. Reflecting the experience of how customers use cross-tenant access settings (Figure 1) in production, on August 30 Microsoft announced some changes due to roll out soon.

The changes are:

• Custom roles for cross-access tenant policy management.
• New method of storing partner policies.
• Integration of blocks in cross-tenant access settings when sending B2B invitations.

Like any other change, these updates might not affect how you work. I think it’s fair to say that the larger the tenant, the more important the updates are to you. But let’s consider what the changes do.

Custom Roles for Cross-Tenant Policy Management

Up to now, only users holding the global administrator or security administrator roles can manage cross-tenant access settings. For most tenants, this arrangement works well. Creating a new cross-tenant arrangement is not something that happens every day and requires coordination with the administrators of the other tenant.

Tenants with Entra ID Premium P1 or P2 licenses can create custom administrative roles to allow users perform specific management tasks for Entra ID. This capability now extends to cross-tenant access policy management where roles such as “Cross-tenant policy reader” might be created to allow users to review but not update settings. Again, this isn’t something that every tenant needs or wants, but at least tenants now have the flexibility to use a custom role to manage cross-tenant access settings if they see value in it.

New Method of Storing Partner Policies

According to Microsoft’s posts, some tenants need to manage cross-tenant access settings for thousands of partners (hopefully, they don’t do this manually and use some form of automation such as PowerShell scripts). Microsoft noted that the way Entra ID stored cross-tenant policy configurations limited the number of individual partner policies that a tenant could manage. Accordingly, a change is rolling out to change the way Entra ID stores policy configurations so that each partner tenant has its own policy. Microsoft says that the new mechanism is scalable and should be capable of storing as many policies as tenants need.

The change to the way Entra ID stores partner policies is happening behind the scenes and shouldn’t be noticed by tenants. Graph APIs interact with policies in the same way for both the old and new storage, so the changeover shouldn’t cause any disruption.

Integration of Blocks with B2B Invitations

The Entra ID B2B Collaboration policy for a tenant can contain a blocklist of tenants that applications aren’t allowed to invite as guest members. For instance, if you add Gmail.com to the blocklist, Entra ID blocks team owners if they attempt to invite people with Gmail.com addresses to become guest members.

The problem is that up to now, Entra ID didn’t check cross-tenant access settings when it assessed whether to send an invitation to a new guest. This meant that you could get into a situation where cross-tenant access settings blocked Contoso.com but the B2B collaboration policy did not. Teams or other applications that use B2B collaboration could go ahead and invite people from Contoso.com to become guest members, but when the Contoso.com users attempted to redeem their invitations and access resources, cross-tenant access settings blocked their attempt.

Obviously, blocking guests who seemed to receive perfectly good invitations is a recipe for frustration for team owners or people who want to share documents and folders from SharePoint Online. The change now being introduced means that Entra ID checks both the B2B Collaboration policy and cross-tenant access settings before deciding to issue an invitation or block a user from an external tenant. It’s a logical way to close a disconnect between two parts of Entra ID.

Learning Through Experience

Cross-tenant access settings are becoming increasingly important. The latest advance is the cross-tenant synchronization used by Microsoft 365 multi-tenant organizations. Synchronization can’t happen if cross-tenant settings aren’t configured correctly. It’s good to see these changes ironing out real-life defects.

Make sure that you’re not surprised about changes that appear inside Office 365 applications by subscribing to the Office 365 for IT Pros eBook. Our monthly updates make sure that our subscribers stay informed.

Azure AD B2B Collaboration and Guest Accounts for SharePoint Sharing

Two recent message center notifications highlight closer integration between SharePoint Online and Azure AD. MC526130 (11 March) says that new tenants created after March 31, 2023 will automatically enable the SharePoint Online integration with Azure B2B integration. Existing tenants aren’t impacted by this change. The associated update, also scheduled for roll-out in late March, is MC525663 (10 March). The news here is that SharePoint Online site sharing will use the Azure B2B Invitation manager instead of the legacy SharePoint Invitation Manager (Microsoft 365 roadmap item 117557).

Rationalization Around Azure AD

The two updates rationalize existing sharing methods with external users and focus on Azure AD as the driving force for managing invitations. The journey toward Azure AD B2B Collaboration started in 2021, so it’s been a while coming. The project makes a lot of sense for both customers and Microsoft (their gain is through reduced engineering expenses).

Ten years ago, it was reasonable for SharePoint to manage site sharing invitations. Today, when the site collection-based architecture is replaced by single-sites and most sharing occurs through Microsoft 365 groups and Teams, it’s illogical for SharePoint Online to have its own mechanism. 280 million monthly active Teams users create a lot of work for SharePoint.

Another factor is that site sharing with external users is a relatively uncommon action today. Most external users join groups or teams and gain access to the group-connected site. Although non-group connected sites do exist, they’re in the minority and some of those sites (like hub and communication sites) aren’t candidates for sharing with external people. And of course, even site owners might be blocked from sharing sites by a sensitivity label.

Time to Review Applicable Policies

Overall, I don’t think the change will disrupt many organizations. As Microsoft notes “You may want to review your Azure B2B Invitation Manager policies.” Two policies are worthy of note. The first is the Azure B2B Collaboration policy, which includes an allow or deny list (but not both) of domains.

The policy is now found under Collaboration restrictions in the External Identities section of the Azure AD admin center (Figure 1). It is commonly used to block sharing with consumer domains (deny list) or to restrict collaboration to a set of known domains belonging to partner organizations (allow list). If the organization already supports guest accounts, it’s likely that the collaboration policy already exists. Even so, changes like this are useful reminders of the need for regular review of any policy that affects how external people access tenant resources.

Azure AD cross-tenant access policies are a more powerful and flexible mechanism to control external access through both Azure B2B collaboration and Azure AD direct connect (used for Teams shared channels). Cross-tenant access policies are still relatively new and don’t need to be implemented unless required for a specific reason, so your tenant might not use them yet.

Although the Azure AD B2B Collaboration policy is likely to dominate for the immediate future, over time, I expect a slow transition to take advantage of the granular control available in cross-tenant access policies. When an organization changes over, SharePoint Online will take advantage. Leveraging advances made in Azure AD is an excellent reason for SharePoint Online to embrace Azure AD more fully.

Review Guest Accounts Too

Azure AD B2B collaboration works but that doesn’t mean that you don’t need to manage guest accounts. As more sharing happens, more guest accounts end up in your Azure AD. Some guest accounts are used once to share a document. Others are in ongoing use as guest members of groups and teams access shared documents. It’s a good idea to keep an eye on guest accounts and remove them as they become obsolete.

Support the work of the Office 365 for IT Pros team by subscribing to the Office 365 for IT Pros eBook. Your support pays for the time we need to track, analyze, and document the changing world of Microsoft 365 and Office 365.

Blocking Guests We Don’t Want to Collaborate With

Updated 12 June 2023

In an earlier post, I cover the basics of updating the Azure AD B2B collaboration settings for a Microsoft 365 tenant. Azure AD B2B collaboration external settings allow the tenant to define a deny list of domains they do not want guest accounts to come from or an allow list to define a restrictive set of domains they’re willing to accept guests from. In my experience, most tenants use a deny list. Once implemented, any attempt to add a new guest account from one of the blocked domains will fail. This happens for applications like Teams and Outlook, and administrative interfaces like the Azure AD admin center (Figure 1).

Azure B2B Collaboration settings work well and no new guest users from domains featuring on its blacklist can be added. However, it does nothing to stop existing guests from those domains continuing to be members of groups and teams within your tenant. Microsoft doesn’t have a facility to detect and remove problem guest users, but it’s relatively easy to do with PowerShell.

The Find Bad Guests Script

We’ve posted a new script called FindBadGuestsFromBlockedDomains.PS1 in the Office 365 for IT Pros GitHub repository. The script works as follows:

• Read the Azure AD B2B Collaboration settings to find if a blacklist of banned domains exists. If some domains are on the blacklist, we continue.
• Find the set of Microsoft 365 Groups (including Teams) with guest members.
• Examine the membership of each group to check if any of the guests come from banned domains.
• Report the results.

When the script finishes processing the set of groups, it generates some basic statistics (Figure 2) and a CSV file.

Cleaning Up Banned Guests

The CSV file (Figure 3) contains the Azure AD object identifier for each guest account found from a banned domain. This is important because you can use this to drive a removal process if necessary.

Before removing a guest account, remember what it will do:

• Remove the guest from memberships of all groups/teams they belong to.
• Remove access to any documents, folders, or lists shared using the guest account.

Before deleting anything, you should review the contents of the CSV file carefully to check that each account really should be deleted. Any guest account that you want to keep should be removed from the file. The updated file can then act as the input for a removal process. For instance, this PowerShell code reads the CSV file and removes the accounts included in the file.

$BadAccounts = Import-Csv c:\temp\BadGuestAccounts.CSV
ForEach ($Account in $BadAccounts) {
   Write-Host "Removing" $Account."Guest Email"
   Remove-AzureADUser -ObjectId $Account.ObjectId }

After removing problem accounts, the remaining guest accounts in the tenant comply with the Azure AD B2B collaboration settings. If you decide to remove guest accounts, it’s probably a good idea to email the group/team owners to let them know what you plan to do, just in case a guest account is required.

Like any of our scripts, the code is written to explain a principal and demonstrate how to construct a solution to a problem. I’m sure the code can be improved, notably by adding better error handling. But it does work (at least in our tenant).

The Office 365 for IT Pros eBook has lots of intensely practical advice to help administrators run tenants. Subscribe to make sure that you benefit from our knowledge.

Deny Guests from Some Domains or Use an Allow List

Updated: 5 September 2023

The ability for applications to use Entra ID B2B collaboration to add guest users is governed by external collaboration settings, aka the Entra ID B2B collaboration policy (previously the Azure AD B2B Collaboration policy). The settings are available through the External identities section of the Entra ID admin center, where they are found under Collaboration restrictions (Figure 1).

Three options are available:

• Allow guest accounts from any external domain. This is the default.
• Deny access to guest accounts from specified domains (deny list).
• Allow access only to guest accounts from specified domains (allow list).

The total size of the policy must be less than 25 KB (25,000 characters). Each domain in an allow or deny list counts against the limit as do other policy settings. Allowing 1,000 bytes for all other settings, an average of 15 characters per domain means that an allow or deny list can accommodate up to 1,600 domains. You can only choose to have a policy with an allow or a deny list and cannot have some domains in a deny list and others in an allow list.

In my case, I use the middle approach to block guest accounts from certain domains. For instance, these might be domains belonging to direct competitors or domains used for consumer rather than business purposes. In Figure 1, you can see that I’ve decided to block access to guests with Google.com and Yahoo.com email addresses.

Entra ID Blocks Bad Guests

Entra ID applies the block rather than applications. For example, in Figure 2, I’ve tried to add a new guest account to Teams, which doesn’t object when I enter tredmondxxxx@yahoo.com to identify the guest. The block descends when Teams tries to create the new guest account in Entra ID. The “Something went wrong” is an uncertain error, but it should be enough for the administrator to know what’s going on when they learn where the guest comes from. OWA doesn’t object to the email address for a new guest but is no more definite in its error (Figure 3). Again, this is because the application fails to create a new guest account in Entra ID.

Knowing What Domains Guests Come From

Before going ahead to update your external collaboration settings, it’s a good idea to understand where current guest accounts come from. This code scans down through guest accounts found in Entra ID to capture details of each user’s home domain. It then populates a hash table with the domain information to create a count for each, followed by sorting in descending order to discover the most popular domains:

$Domains = [System.Collections.Generic.List[Object]]::new()
Connect-MgGraph -NoWelcome -Scopes Directory.Read.All
[array]$Guests = (Get-MgUser -All -Filter "UserType eq 'Guest'" | Select-Object Displayname, UserPrincipalName, Mail, Id | Sort DisplayName)

ForEach ($Guest in $Guests) {
   $Domain = ($Guest.UserPrincipalName.Split("#EXT#")[0]).Split("_")[1]
   $Domains.Add($Domain)
}

$DomainsCount = @{}
$Domains = $Domains | Sort-Object
$Domains | ForEach {$DomainsCount[$_]++}
$DomainsCount = $DomainsCount.GetEnumerator() | Sort-Object -Property Value -Descending
$DomainsCount


Name                           Value
----                           -----
microsoft.com                  59
outlook.com                    11
quest.com                      6
hotmail.com                    5
gmail.com                      4
emea.teams.ms                  4

Now you know what domains are actively in use, you can decide which you might like to ban. Remember that putting a domain on the deny list stops only the creation of new guest accounts. Existing guest accounts remain in the membership of groups and teams. If you want to purge accounts from unwanted domains, you need to find the groups (teams) with guest members and examine each guest to decide if they can stay or be removed. It’s easy enough to find guests from banned domains with PowerShell, or so the saying goes…

The Office 365 for IT Pros eBook is packed full of practical information like this. Learn from the pros by subscribing to Office 365 for IT Pros and receive monthly updates during your subscription period.