Information Barriers, Teams, and Problems Adding New Guest Accounts

Information Barrier Policies and Organization Segments

Microsoft introduced Information Barriers earlier this year as a replacement for address book policies to segment accounts within tenant directories in a way that could be used by all Office 365 applications. The basic idea is that Information Barrier polices control who can communicate with others within an Office 365 tenant. Organization segments define sets of users and policy rules dictate how segments can communicate.

Teams Has Problems with New Guest Accounts

Exchange Online and Teams are the first applications to support Information Barriers. For Exchange Online, the switch from address book policies to Information Barriers is transparent. Most functionality works smoothly with Teams too, with the notable exception that team owners can’t create a new guest user account to the tenant by adding them to a team’s membership.

Existing guest accounts don’t cause problems because Teams can check that adding them to a team membership won’t violate a policy. Teams does this by calling the directory services API to check what organization segments the guest belongs to. When an attempt is made to add a new guest, the call fails because the account doesn’t exist in the Exchange Online directory store (EXODS). Teams can’t validate that the barrier is respected, and the attempt fails (Figure 1).

Teams can't add a new guest account to team membership
Figure 1: Teams can’t add a new guest account to team membership

Unfortunately, apart from being told that Teams ran into an issue, no clues are given to the team owner as to what went wrong. Despite being told that a problem happened, behind the scenes the guest account is created in the tenant directory and an Azure B2B Collaboration invitation goes to the guest’s email address (Figure 2).

The invitation to join the team arrives in the guest's mailbox
Figure 2: The invitation to join the team arrives in the guest’s mailbox

When the guest tries to redeem the invitation and log into Teams, Azure Active Directory validates the invitation but when Teams starts, the guest discovers that they don’t have membership of the group they were invited to join (Figure 3).

Whoops! No access to the team for the guest
Figure 3: Whoops! No access to the team for the guest

An Easy Workaround

The workaround is simple: create the guest account through the Azure Active Directory portal or by adding them to the membership of the underlying Office 365 group using Outlook or OWA. The addition of the new member will be replicated to Teams and any Information Barrier checks will then be imposed. Microsoft is aware that this situation is unsatisfactory and is working on a fix.


To learn more about Information Barriers, read Chapter 19 of the Office 365 for IT Pros eBook. The book also includes a ton of information about Teams management.

5 Replies to “Information Barriers, Teams, and Problems Adding New Guest Accounts”

  1. Hi Tony,

    Good article – very useful, thanks. I don’t suppose you have any wisdom as to whether it’s a requirement to purchase the relevant compliance SKU or bundle (E5 Compliance or Insider Risk) for each guest user if they are added to segments for Info Barriers? MS have suggested they need to be, but that’s not how most guest access is done, they often say you can have, for instance, five guests per internal licence). For my client, that would add a massive cost if we have to buy a SKU/bundle for every guest. I have your book and was hoping it would be covered in there (great book BTW).

    1. Guest users are licensed for the standard Teams features but once you get into the realms of extended functionality, all bets are off. The relevant guidance for information barriers is at https://docs.microsoft.com/en-us/office365/servicedescriptions/microsoft-365-service-descriptions/microsoft-365-tenantlevel-services-licensing-guidance/microsoft-365-security-compliance-licensing-guidance#information-barriers and says “For scenarios in which two groups cannot communicate with each other, users in both groups require a license to benefit from the service (see below example).” From this text, I read it to mean that guests in the relevant groups would need licenses. But feel free to argue the point with your Microsoft licensing specialist…

      1. Thanks Tony. I would read that statement in the same way – it will be a debate with MS – given the cost of the add-ons, it makes a difficult business case if we need to licence all guests. I really appreciate your thoughts on this.

      2. Like any licensing discussion with Microsoft, you might find room for maneuver, especially in the context of an enterprise agreement.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.