Controlling Communications inside Office 365 Tenants with Information Barriers (Part 2)
Introducing Teams to Information Barriers
The first article in this series covered the preparatory work necessary to introduce Information Barriers into an Office 365 tenant. This article looks at how Teams implements Information Barriers and what you can expect to see when policies are in place to restrict user communications.
I don’t intend repeating Microsoft’s instructions about how to configure Information Barriers. Instead, this article reports some practical notes on the process of implementing Information Barriers for Teams.
Components to Block Teams Communications
Teams uses several components in its Information Barrier implementation, including:
- Organization segments (common across all Office 365 workloads) to define sets of users.
- Information Barrier policies to define what sets of users can communicate with each other.
- Background processes to apply the settings in Information Barrier policies to personal chats, team memberships, meetings, and VOIP calls.
In addition, the restrictions that could previously be applied by Teams clients to directory lookups using ABPs are now applied by Information Barriers.
Scoping the Directory
The first thing to do is to enable directory scoping for Teams (Figure 1). This step tells Teams to respect any restrictions set by filters to block users seeing specific parts of the tenant directory. Setting directory restrictions has some side-effects on Teams functionality.
Giving Permissions to Stop Chats
Another prerequisite is to give permission to an app to stop chats between people barred by policy. The PowerShell commands to assign permissions to the app use the older Azure RM module rather than the newer Azure AZ module. It would be good if this was specified in Microsoft’s documentation.
Applying the Barriers
The last article stopped after we created two Information Barrier policies to control communications. After activating the policies, we need to make Teams aware that some policies exist.
After connecting a PowerShell session to the Security and Compliance Center endpoint, run the Start-InformationBarrierPoliciesApplication cmdlet to begin the process of applying the policy conditions to the affected users.
Start-InformationBarrierPoliciesApplication
Microsoft says that it can take some time before the policy is fully effective for all users and cites the example of an hour being needed to apply a policy to 5,000 accounts. To check the status of the policies, run the Get-InformationBarrierPoliciesApplicationStatus cmdlet. Here we see that 4,338 recipients were processed, most of which were mail contacts.
Get-InformationBarrierPoliciesApplicationStatus RunspaceId : 6f427633-0a48-4f57-9c84-ec5e8bb946f1 Identity : b4cf044a-e915-4960-9baa-7804415c2a3a CreatedBy : Administrator CancelledBy : Type : ExoApplyIBPolicyJob ApplicationCreationTime : 06/26/2019 21:11:54 ApplicationEndTime : 06/26/2019 22:22:19 ApplicationStartTime : 06/26/2019 21:11:54 TotalBatches : 5 ProcessedBatches : 5 PercentProgress : 100 TotalRecipients : 4343 SuccessfulRecipients : 4343 FailedRecipients : 0 FailureCategory : None Status : Completed
You might notice that all mail recipients, including mail contacts, in a tenant are processed. This is to make sure that the address book segmentation functionality works for all types of recipient.
Microsoft’s SLA for the Information Barrier application to detect a change in an account’s properties that impact a barrier policy is 24 hours. However, usually changes like updating someone’s department are picked up faster (3-4 hours). The thing to realize is that it takes time for all the moving parts within Office 365 to react to changes in the directory and to set expectations accordingly. Updating someone’s role at 9am does not mean that they’ll be barred from communicating with others by 9:30am. This is especially true when the directory is in a state of churn due to department reorganizations or other major changes.
If a problem occurs in deploying information Barrier policies or you make changes to policies, you can run the Start-InformationBarrierPoliciesApplication cmdlet to process all active policies.
Checking User Accounts
After an account is processed, it is assigned an Information Barriers GAL that takes precedence over the default GAL. In effect, this is the replacement for Exchange ABPs.
Get-Mailbox Andy.Ruth | Select -ExpandProperty addresslistmembership \IBPolicyGAL_1bd52480-82f2-4416-814a-022776e46bef \Default Global Address List \Mailboxes(VLV) \All Users \Offline Global Address List \All Mailboxes(VLV) \All Recipients(VLV)
You’ll also see that the organization segment the user belongs to is returned by the Get-Recipient cmdlet.
Get-Recipient -Identity Andy.Ruth | Format-Table In*
InformationBarrierSegments
--------------------------
{352e1fe3-fbee-4980-9208-103ddea4b370}
Which means that we can check the membership of an organization segment by running a query using the GUID for a segment:
Get-Recipient -RecipientTypeDetails UserMailbox, GuestMailUser |?{$_.InformationBarrierSegments -eq "352e1fe3-fbee-4980-9208-103ddea4b370"}| Format-Table Displayname
It’s important to realize that it might take some time before the organization segments are acceptably accurate. There’s also the small matter of synchronization and client caching to consider as it will take more time for clients to update their view of the world and begin to respect barriers.
How Teams Uses Information Barriers
Teams imposes blocks to implement Information Barriers at several points.
Team membership. If a team owner tries to add someone to a team when a member already exists who is blocked from communicating with the new potential member, Teams won’t allow the new member to be added (Figure 2).
For existing memberships of teams, if a background scan detects a violation, the Information Barrier Processor removes members to bring the team into compliance. Service messages for the account removals are posted to the team’s General channel (Figure 3).
All members of a team who shouldn’t be in the team are removed by the Information Barrier Processor. This includes owners if they are in violation, which means that a team can be left ownerless. Removals are recorded in the Office 365 audit log where you’ll see that the user removing the account from the group is noted as “ServicePrincipal_Guid.”
It seemed to me that removals were processed on a last-in, first-out basis: in other words, the last person who joins a team and causes a violation is removed and existing members are left in place. However, this isn’t always the case as it depends on when organization segments or individual accounts change, and those changes are picked up by the Information Barrier Processor.
Chats: Teams won’t start the chat if the participants are blocked by policy. At least, Teams will start a chat, but the only participant will be the person who tries to communicate with others. Figure 4 shows what happened when I tried to start a group chat with two other users who were blocked by policy from communicating with each other. If other people who can communicate with each other had been added to the chat, they remain in the chat.
Joining meetings: When an account tries to join a meeting, Teams blocks them if other participants blocked by policy are in the meeting.
Screen sharing: Any time someone shares their screen in a meeting, Teams checks for policy violations and won’t allow the sharing if a violation is detected.
VOIP calling: When someone calls another person or a group, Teams checks the call to make sure that it doesn’t violate a policy and terminates the call if a violation is detected. This won’t stop someone using PSTN calling to call someone who is otherwise blocked.
Users blocked from communicating with each other won’t be able to see blocked accounts in organization charts, activity feed, suggested contacts, people cards, and call and chat contacts. I found there were some edge cases, such as when one user blocked from communicating with another person could see that person’s details in the organization chart because they were a direct report (Figure 5). I suspect that some software tweaks will rapidly impose a barrier on this kind of information leakage soon.
In addition, whenever Information Barrier or user accounts are updated, the Information Barrier Policy Evaluation Service evaluates existing chats and team memberships to ensure that no policy violation results from the update. Existing 1:1 chats become read-only if Teams finds that participants are blocked by policy (Figure 6). The messages in the chat before the violation was detected remain untouched.
Administrative Interfaces and Information Barriers
Although Teams can control the addition of members and how members communicate, it can’t control how members are added to Office 365 Groups through administrative interfaces, especially as most of the administrative interfaces inside Office 365 know nothing about Information Barriers.
For instance, you can add a prohibited team membership using the Teams Admin Center or the Office 365 Admin Center. Likewise, you can do the same by running the Add-UnifiedGroupLinks, Add-TeamUser, or Add-AzureADGroupMember PowerShell cmdlets. Although all these actions result in blocked members in group membership, they will not make it through the synchronization process that updates Teams from Azure Active Directory as the violation will be detected and blocked at this time. The members of the group that cause the violation will then be removed by the Information Barrier Processor.
The Information Barrier Processor is a backstop to eliminate violations introduced through interfaces that have no knowledge (yet) of Information Barrier policies.
Audit Events
Information Barriers record several new audit events in the Office 365 audit log, including the following operations:
- New-ExoInformationBarrierSegment: when new organization segment is created.
- RecipientChange: when an account is updated because of Information Barrier settings.
- ApplyBIPolicy: when an account is evaluated for information Barrier policies.
No Software Stops Communication
Information Barriers won’t stop Office 365 users communicating with each other. In fact, in practical terms, no software barrier will stop people communicating. Information Barriers don’t stop users emailing each other if they know each other’s SMTP address. This is the reason why you might want to use Office 365 supervision policies to check email flowing between different parts of the organization or implement ethical firewalls with transport rules, especially if you want to control communication to specific domains.
It’s also true that Information Barriers won’t stop users sending messages to VIP mailboxes, which is why mailbox moderation exists. Because all messages stay within a tenant, Information Barriers are more effective in stopping chat and voice communication with Teams, but again, they won’t stop someone using a PSTN number to dial up another Teams user for a voice call.
If they’re stopped using email and Teams, people will find another route to share information, be it WhatsApp, a simple text message, or a surreptitious note scrawled on a scrap of paper. But that’s not the point of Information Barriers or why you would want to deploy these policies. Instead, having policies like this in place helps organizations satisfy regulatory requirements in a demonstratable and provable manner. And if people really want to do wrong, HR processes should be defined, available, and communicated to enforce company policy in a way that humans understand.