This pic above is exactly the opposite of how information barriers work.
Table of Contents
So how it works?
When information barrier policies are in place, people who should not communicate or share files with other specific users won’t be able to find, select, chat, or call those users. With information barriers, checks are in place to prevent unauthorized communication and collaboration.
Information barriers applies to Microsoft Teams (chats and channels), SharePoint Online and OneDrive. In Microsoft Teams, information barrier policies determine and prevent the following kinds of unauthorized communications:
- Searching for a user
- Adding a member to a team
- Starting a chat session with someone
- Starting a group chat
- Inviting someone to join a meeting
- Sharing a screen
- Placing a call
- Sharing a file with another user
- Access to file through sharing link
If the people involved are included in an information barrier policy to prevent the activity, they will not be able to proceed. In addition, potentially, everyone included in an information barrier policy can be blocked from communicating with others in Microsoft Teams. When people affected by information barrier policies are part of the same team or group chat, they might be removed from those chat sessions and further communication with the group might not be allowed.
In SharePoint Online and OneDrive, information barrier policies determine and prevent the following kinds of unauthorized collaborations:
- Adding a member to a site
- Accessing site or content by a user
- Sharing site or content with another user
- Searching a site
Required licenses and permissions
Although IB is a Tenant level service and you could use it without enabled license, you are not allowed to do so.
- Microsoft 365 E5/A5 subscription (paid or trial version)
- Office 365 E5/A5/A3/A1 subscription (paid or trial version)
- Office 365 Advanced Compliance add-on (no longer available for new subscriptions)
- Microsoft 365 E3/A3/A1 subscription + the Microsoft 365 E5/A5 Compliance add-on
- Microsoft 365 E3/A3/A1 subscription + the Microsoft 365 E5/A5 Insider Risk Management add-on
Known Issues
- Users can’t join ad-hoc meetings: If IB policies are enabled, users aren’t allowed to join meetings if the size of the meeting roster is greater than the meeting attendance limits. The root cause is that IB checks rely on whether users can be added to a meeting chat roster, and only when they can be added to the roster are they allowed to join the meeting. A user joining a meeting once adds that user to the roster; hence for recurring meetings, the roster can fill up fast. Once the chat roster reaches the meeting attendance limits, additional users cannot be added to the meeting. If IB is enabled for the organization and the chat roster is full for a meeting, new users (those users who aren’t already on the roster) aren’t allowed to join the meeting. But if IB isn’t enabled for the organization and the meeting chat roster is full, new users (those users who aren’t already on the roster) are allowed to join the meeting, though they won’t see the chat option in the meeting. A short-term solution is to remove inactive members from the meeting chat roster to make space for new users. We will, however, be increasing the size of meeting chat rosters at a later date.
- Users can’t join channel meetings: If IB policies are enabled, users aren’t allowed to join channel meetings if they’re not a member of the team. The root cause is that IB checks rely on whether users can be added to a meeting chat roster, and only when they can be added to the roster are they allowed to join the meeting. The chat thread in a channel meeting is available to Team/Channel members only, and non-members can’t see or access the chat thread. If IB is enabled for the organization and a non-team member attempts to join a channel meeting, that user isn’t allowed to join the meeting. However, if IB is not enabled for the organization and a non-team member attempts to join a channel meeting, the user is allowed to join the meeting—but they won’t see the chat option in the meeting.
- Maximum number of segments allowed in a organization: Each organization can set up to 100 segments when configuring IB policies. There is no limit on the number of policies that can be configured.
- IB policies don’t work for federated users: If you allow federation with external organizations, the users of those organizations won’t be restricted by IB policies. If users of your organization join a chat or meeting organized by external federated users, then IB policies also won’t restrict communication between users of your organization.
How to use attributes in information barrier policies
PowerShell way
Example | Cmdlet |
Define a segment called Segment1 using the Department attribute | New-OrganizationSegment -Name “Segment1” -UserGroupFilter “Department -eq ‘Department1′” |
Define a segment called SegmentA using the MemberOf attribute (suppose this attribute contains group names, such as “BlueGroup”) | New-OrganizationSegment -Name “SegmentA” -UserGroupFilter “MemberOf -eq ‘BlueGroup'” |
Define a segment called DayTraders using ExtensionAttribute1 (suppose this attribute contains job titles, such as “DayTrader”) | New-OrganizationSegment -Name “DayTraders” -UserGroupFilter “ExtensionAttribute1 -eq ‘DayTrader'” |
Attributes that can be used.
Azure Active Directory property name (LDAP display name) | Exchange property name |
---|---|
Co | Co |
Company | Company |
Department | Department |
ExtensionAttribute1 | CustomAttribute1 |
ExtensionAttribute2 | CustomAttribute2 |
ExtensionAttribute3 | CustomAttribute3 |
ExtensionAttribute4 | CustomAttribute4 |
ExtensionAttribute5 | CustomAttribute5 |
ExtensionAttribute6 | CustomAttribute6 |
ExtensionAttribute7 | CustomAttribute7 |
ExtensionAttribute8 | CustomAttribute8 |
ExtensionAttribute9 | CustomAttribute9 |
ExtensionAttribute10 | CustomAttribute10 |
ExtensionAttribute11 | CustomAttribute11 |
ExtensionAttribute12 | CustomAttribute12 |
ExtensionAttribute13 | CustomAttribute13 |
ExtensionAttribute14 | CustomAttribute14 |
ExtensionAttribute15 | CustomAttribute15 |
MSExchExtensionCustomAttribute1 | ExtensionCustomAttribute1 |
MSExchExtensionCustomAttribute2 | ExtensionCustomAttribute2 |
MSExchExtensionCustomAttribute3 | ExtensionCustomAttribute3 |
MSExchExtensionCustomAttribute4 | ExtensionCustomAttribute4 |
MSExchExtensionCustomAttribute5 | ExtensionCustomAttribute5 |
MailNickname | Alias |
PhysicalDeliveryOfficeName | Office |
PostalCode | PostalCode |
ProxyAddresses | EmailAddresses |
StreetAddress | StreetAddress |
TargetAddress | ExternalEmailAddress |
UsageLocation | UsageLocation |
UserPrincipalName | UserPrincipalName |
WindowsEmailAddress | |
Description | Description |
MemberOf | MemberOfGroup |
The GUI way, still in preview
Microsoft is all the time heavily adding new options for their products and some of them goes with out us even noticing.
There is one for Information Barriers Segments, which is again a nice addition to comply with easiness of use.
It can be found under Compliance -> Information Barriers -> Segment
Here you can add your segments (with the same attributes that was shown before in this post.
Then you will create the segment and you can use this group inside your segment.
You will create two segments.
Then to policies
Policies is also in preview.
Create policy and select the first segment.
In the next screen you will choose will you block or allow the other segment.
And set status On or Off
Now you have the Segments and the corresponding policy.
And then to Policy application.
Run “Apply All Policies”
And you will get and error saying, that the policy should be symmetric.
Go to create a new policy.
Then again to Policy application. Now you will notice that the applying is starting.
And eventually it will change to Apply In progress.
And the done, so it took about 20 minutes to complete.
What happens after policy is applied?
When you try to send Teams message to the user in the other segment, this will happen.
But with email it still wont work. Like it was before.