Last Update: Sep 05, 2024 | Published: Jul 25, 2019
Those working with Exchange are probably familiar with the concept of an ethical firewall, a barrier erected in software to stop defined sets of users communicating with each other. In the past, bespoke customizations like transport sinks were written for this purpose. Usually the firewalls were deployed by organizations operating in highly regulated industries. For instance, a bank might stop traders and brokers communicating. Since the advent of transport rules in Exchange 2007, the job is usually done by creating transport rules to stop groups communicating.
Ethical firewalls continue in Exchange Online, but now we have other methods of communications, notably Teams. Announced in preview in April and now generally available, Information Barriers deliver the answer for Office 365 by preventing sets of users communicating through all Office 365 workloads.
Figure 1 shows the Office 365 Information Barrier architecture (as presented at Ignite 2018) to control access across Exchange Online, SharePoint Online, Teams, and OneDrive for Business.
This article explores the concepts behind Information Barriers and the steps needed to prepare for their introduction into an Office 365 tenant. The next article looks at the implementation of Information Barriers in Teams.
Teams and Exchange Online are the first workload to support Information Barriers. For Exchange Online, Information Barriers replace Address Book Policies (ABPs), which restrict user access to the directory and have been in use since Exchange 2010. Information Barriers don’t do anything more for Exchange, so they are currently a straight functional swap for ABPs.
Office 365 accounts who come under the control of Information Barrier policies need an Office 365 E5 license or the Advanced Compliance add-on.
Information Barriers replace Exchange Address Book Policies (ABPs). In fact, you can’t create any information Barrier policies until all ABPs have been removed from the organization. When active, the Information Barrier policies serve the same purpose as ABPs by preventing users seeing other people in the directory whom they are not allowed to communicate with.
If your organization uses ABPs today, the need to replace them is an important aspect of planning for Information Barriers. It would have been good if Microsoft had done more to highlight this fact in its documentation instead of inserting a note in the prerequisites:
“No address book policies. Before you define and apply information barrier policies, make sure no Exchange address book policies are in place. If you do have such policies, make sure to remove your address book policies first.”
This prerequisite is easy if your organization doesn’t make much use of ABPs. Unfortunately, Microsoft’s advice hides a lot of pain for an organization that has invested in ABPs. These organizations tend to be large and complex, which is why they use ABPs in the first place.
Removing an ABP from an active mailbox is easy. First find the mailboxes stamped with the relevant ABP:
Get-Mailbox -IncludeInactiveMailbox | ? {$_.AddressBookPolicy -eq "Engineering ABP"}
Now, run Set-Mailbox to remove the assignment. Note that this only works for active mailboxes.
Set-Mailbox -Identity Kim.Akers -AddressBookPolicy $Null
Things become more complicated when inactive mailboxes are in the picture. If any of these mailboxes were assigned ABPs when active, you must restore them to remove the ABP assignment. For example, let’s say that you need to find inactive mailboxes that have been assigned the “Engineering ABP.” This command will do the trick:
Get-Mailbox -InactiveMailboxOnly | ?{$_.AddressBookPolicy -eq $Null} | Format-Table Name, PrimarySmtpAddress, ExchangeGuidRestore inactive mailbox
You now need to restore each of these mailboxes by running the New-Mailbox cmdlet (unless the mailboxes were deleted within the last 30 days, in which case you can run the Undo-SoftDeletedMailbox cmdlet). In my case, the relevant inactive mailboxes were reasonably old, so I recovered them by running a command like:
New-Mailbox -InactiveMailbox a74ce6db-80cc-427b-97e3-ff027cde8e54 -MicrosoftOnlineServicesID [email protected] -name "Natasha Jones"
Recovering an inactive mailbox creates a new mailbox and the ABP assignment is blank, so once you have recovered all the inactive mailboxes and cleared the ABP assignments from active mailboxes, you can remove ABPs by running the Remove-AddressBookPolicy cmdlet. For example:
Remove-AddressBookPolicy -Identity “Engineering ABP”
The sets of users that come under the control of Information Barriers are referred to as organization segments. Information Barrier policies define which segments can communicate with each other or those blocked from communication. The first step in implementing Information Barriers is to define organization segments for the users whose communication should be controlled. You don’t have to create segments for the entire organization, but if you don’t, the risk exists that some users will be able to communicate where they should be barred.
Segments are defined by properties of Azure Active Directory accounts. Microsoft suggests that you use the same property as the basis for all segments. In other words, if you decide to divide the organization by department, use the department property for all segments. It’s also best if the segments don’t overlap (multiple segments cover the same set of accounts).
To explain the concept, Microsoft documents how the fabled Contoso organization creates suitable segments and uses those segments in Information Barrier policies.
It’s safe to say that not every instance of Azure Active Directory is perfectly populated. It’s important to check that the properties of Azure Active Directory accounts used to define segments are populated with the right values. For this example, we’re going to segment by department, so each account needs a valid department value. We can use the Office 365 Admin Center (Figure 2) to examine the properties of user account (unfortunately the Admin Center doesn’t support sorting by department).
Looking through a GUI for missing or invalid values can become tiresome. As is often the case, PowerShell comes in handy to identify any directory problems that must be fixed before proceeding to implement Information Barrier policies. Here’s how to find accounts that don’t have a department filled in:
Get-AzureADUser -all $True -Filter "UserType eq 'Member'" | ?{$_.Department -eq $Null} | Format-Table UserPrincipalName, Displayname, Department -AutoSize
The data returned by Azure Active Directory includes the accounts used for shared mailboxes and room mailboxes. An alternative is to use the Get-Recipient cmdlet and filter the search to return just accounts with user mailboxes:
Get-Recipient -RecipientTypeDetails UserMailbox -ResultSize Unlimited | Format-Table Name, WindowsLiveId, Department -AutoSize
In either case, you can export the result to a CSV file and use that as the basis for finding accounts that need to be updated with accurate department details. Here’s what I used:
Get-AzureADUser -all $True -Filter "UserType eq 'Member'" | Select Department, DisplayName, UserPrincipalName, PhysicalDeliveryOfficeName | Sort Department | Export-CSV -NoTypeInformation c:tempUsersDepartments.csv
An ISV tool like Hyperfish will help you get your directory straightened out if you don’t want to do the work with PowerShell.
After applying all the updates, make sure to do a final pass to check that all the department information is correct. There are normally typos to be fixed. The typos might be acceptable to a human, but they mean that the filters used by Information Barriers won’t work as expected. In short, it is critical that the directory properties you use to segment the organization are as accurate as you can make them.
Information Barrier policies work by either allowing or blocking segments communicating with each other. To create a policy, we must first define the segments. Each segment has a filter to tell Azure Active Directory what accounts come within its scope. Think of this like the filter used by a dynamic group.
Our example scenario establishes an ethical firewall for Teams to stop staff in the Trading and Sales departments communicating with each other. To do this, we need two segments: one defines the accounts in the Trading Department, the other defines the accounts in the Sales Department. Currently, you can only create and maintain Information Barrier policies with PowerShell. The cmdlets to work with Information Barriers are available by connecting a PowerShell session to the Security and Compliance Center endpoint.
New-OrganizationSegment -Name "Trading Department" -UserGroupFilter "Department -eq 'Trading'" New-OrganizationSegment -Name "Sales Department" -UserGroupFilter "Department -eq 'Sales'"
These segments use simple queries. You can construct more complex queries (anything that can be executed against Azure Active Directory) and use those to define segments. Guest accounts are included in organization segments and supported by Information Barriers.
To test the effectiveness of the query used in an organization segment, we can apply the query when running the Get-AzureADUser cmdlet. For example:
Get-AzureADUser -Filter "Department eq 'Sales'" | Format-Table Displayname, UserPrincipalName DisplayName UserPrincipalName ----------- ----------------- Andy Ruth (Director) [email protected] James Abrahams [email protected] Flayosc Worker flayosc_yandex.com#EXT#@office365itpros.onmicrosoft.com
Alternatively, you can check for an individual user with the Get-InformationBarrierRecipientStatus cmdlet, but only after Information Barrier policies are deployed.
Get-InformationBarrierRecipientStatus -Identity Andy.Ruth -Identity2 JAbrahams
Once we’re happy that the organization segments identify the right people, we can proceed to link them in two Information Barrier policies. One will stop people in trading communicating with sales; the other blocks the reverse traffic.
New-InformationBarrierPolicy -Name "Trading Block Sales" -AssignedSegment "Trading Department" -SegmentsBlocked "Sales Department" -State Inactive New-InformationBarrierPolicy -Name "Sales Block Trading" -AssignedSegment "Sales Department" -SegmentsBlocked "Trading Department" -State Inactive
The Information Barrier policies are created in an inactive state. This is recommended because it allows administrators to set everything up (and do some testing) before activating policies across the organization.
To activate a policy, run the Set-InformationBarrierPolicy cmdlet to change the state to Active.
Set-InformationBarrierPolicy -Identity "Trading Block Sales" -State Active
Information Barriers also support the concept of an allow list to allow segments to only communicate with one or more other segments. For example, this command permits communications between accounts in the Group HQ segment with five other segments.
New-InformationBarrierPolicy -Name "Group HQ Communications" -AssignedSegment "Group HQ" -SegmentsAllowed "Sales Department", “Marketing”, “Research”, “Trading Department”, “Engineering”
Just like Address Book Policies, if Office 365 workloads can’t find a policy to block or allow communication between two accounts, it assumes that communication is allowed.
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.
Teams uses several components in its Information Barrier implementation, including:
In addition, the restrictions that could previously be applied by Teams clients to directory lookups using ABPs are now applied by Information Barriers.
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.
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.
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.
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.
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.
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.
Information Barriers record several new audit events in the Office 365 audit log, including the following operations:
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.