Azure Active Directory External Collaboration Policy Now Generally Available

Posted on April 26, 2018 by Tony Redmond in Microsoft Teams, Office, Office 365 with


A Policy to Govern Office 365 External Collaboration

In August 2017, I reported on the preview of a policy to block external access for guest accounts created by Azure B2B Collaboration and used by applications like Office 365 Groups, Teams, and Planner. At that time, the interface to the policy was a PowerShell script. Now, the policy is generally available complete with some user interface to guide administrators who don’t like messing with scripts. The policy is available to all Azure AD customers without the need for a special license.

External Collaboration Settings

To access policy settings, click the External collaboration settings link in User settings in the Azure Active Directory portal, and then the section called Collaboration restrictions. Three values are available:

  • Allow invitations to be sent to any domain (most inclusive): This is the default setting and it means that invitations to join Office 365 Groups and Teams can go to users in any other domain.
  • Deny invitations to the specified domains: You can create a policy to block invitations going to specific domains. Microsoft believes that using a deny list is the most common scenario as most organizations know the domains that they do not wish to share information with. For example, if you decide that you do not want users to invite guest users with consumer email addresses, you block domains like,,,, and so on. When a deny list is in place, Office 365 blocks any attempt to invite someone to join a group or team if the invitee has an email address in one of the blocked domains.
  • Allow invitations only to the specified domains (most restrictive): You can create a policy with an allow list, meaning that invitations can only go to domains in the list. Office 365 blocks any attempt to generate invitations to any other domain not on the list. This choice is greyed out because Microsoft has not completed development.

The policy settings are in an Azure Active Directory policy called B2BManagementPolicy. To create a policy with a deny list, click the deny list button and enter the domains to include and then Save (Figure 1). You can add up to 60 domains to a block or allow list. After you populate the allow list, the policy applies to all applications that use Azure B2B collaboration for external sharing, including Office 365 Groups and Teams.

Azure B2B Collaboration deny

Figure 1: Adding domains to a deny list for the collaboration policy (image credit: Tony Redmond)

Either Deny or Allow

A tenant can only have a deny or an allow list. If you think that an allow list will work better than a deny list that is already in place, you must remove the current deny list and then create the allow list. The external collaboration deny or allow list is separate to the list that you can create to restrict sharing for OneDrive for Business and SharePoint Online. One list blocks invitations to join groups or teams, the other blocks invitation to share documents or folders.

As you might expect, it is best if you maintain consistency in the block or allow lists used for Azure B2B Collaboration and SharePoint. That way you’ll avoid situations such as a guest being able to access Teams (because Azure B2B Collaboration allows) while not being able to access the document library belonging to the team (because they are blocked by SharePoint).

Adding Guests with a Block

When a deny list is active, group-enabled applications that support guests use the list to know whether they should block new members from the domains on the list. When I tested the policy on April 18, OWA generated a better error message when I tried to add a member from a blocked domain to an Office 365 group (Figure 2) than Teams did (Figure 3).

OWA error deny guest

Figure 2: OWA signals a blocked user (image credit: Tony Redmond)

Teams error add deny guest

Figure 3: Teams error when trying to add a user from a blocked domain (image credit: Tony Redmond)

The Teams error message is misleading because it leaves some hope that the error is transient, and it might be possible to add the guest later. No doubt the Teams development group will fix the problem in one of their frequently-updated future builds.

Outlook desktop for Windows was in the middle and reported “there was a problem adding one or more people to the group. For help, contact your administrator.” Outlook for iOS reported that it couldn’t add members either, saying that “something went wrong” and “please try again later.” Clearly, Microsoft needs to do some rationalization of error messages across group-enabled clients.

PowerShell for Stringfied JSON

The PowerShell module for Azure Active Directory (version or later) includes cmdlets to create and manage an AAD policy to implement block and allow lists to control the domains to which guests belong. For example, to see details of the policy created above, use the Get-AzureADPolicy cmdlet:

You can also manipulate policy settings with PowerShell, as in this example of using the Set-AzureADPolicy cmdlet. However, it can be tricky to construct the “stringfied JSON” (Microsoft’s term) used to pass the new policy rules, so it is usually easier to work with deny or allow lists through the Azure Active Directory portal.

Finding Unwanted Guests

Even with an allow or block list in place, it is possible that some unwanted guests already exist in group memberships because group owners added them before you implemented the block, or because you forget to add a domain to the blocked list. To fix the problem, you can scan the memberships of groups with guests to check where guests come from.

Because Groups and Teams share common membership, this code reports guests added through Teams too. This script does the job and tells us how many guest memberships, how many groups have guests, and which group has the largest number of guests. Make sure that you replace the reference to @tenant in the code with your tenant name.

Of course, knowing if you have unwanted guests is one thing. Getting rid of them is another. Before rushing to remove the guest accounts, it’s probably a good idea to ask the owner of the relevant team or group why the person is a member. Failure to give an adequate explanation is grounds for removal…

Controlling Access is Good

In a perfect world, we might like to share freely and openly with everyone. But we don’t live in a perfect world and it is right that organizations control with whom they share information. Putting a deny list in place to block sharing with competitors is an easy decision. Thankfully, the GUI makes it as easy to create and implement the block list as it is to make the decision.

Follow Tony on Twitter @12Knocksinna.

Want to know more about how to manage Office 365? Find what you need to know in “Office 365 for IT Pros”, the most comprehensive eBook covering all aspects of Office 365. Available in PDF and EPUB formats (suitable for iBooks) or for Amazon Kindle.

Tagged with , , , ,