Microsoft Purview Information Barriers v2 (IB v2) is now generally available for all new onboarding customers. IB v2 has enhanced architecture which enables the following new features:
Large-scale segment support: The segment limit in organizations has increased to 5,000.
Multi-segment support: Users can be assigned to up to 10 segments.
Flexible user discoverability: Organizations can now choose to allow IB-protected users to discover each other while adhering to IB communication and collaboration policies.
What is Information Barriers?
Microsoft Purview Information Barriers (IB) is a comprehensive compliance platform that allows regulated customers in finance (FSI), legal, consulting verticals to meet compliance requirements to 'protect communication and collaboration across internal regulated users'. IB was first released for Microsoft Teams in 2019. Since the initial release, IB has expanded from Teams to also support OneDrive for Business and SharePoint Online.
New capabilities with IB v2
Large-scale segment support
A big improvement with IB v2 is large scale segment support per tenant. For IB v1, the maximum number of defined segments in a tenant was 250. With IB v2, this limit is increased to 5,000 segments per tenant. This new scale doesn’t require any extra IB configuration changes by organizations using IB v2.
Multi-segment support
The new multi-segment organization mode enables administrators to assign users in your organization to up to 10 segments in IB, instead of being limited to just one segment. This allows support for more diverse communication rules between users and groups and supports more complex organizational and operational scenarios. For more information, see Use multi-segment support in information barriers.
Figure 1: Enable multiple segment support for your organization
Flexible user discoverability
IB v2 now allows administrators to enable or disable user discoverability restrictions in IB. Once user discoverability restricted by IB is turned off, users can discover each other in the people picker, independent of their IB policies.
By default, the people picker restriction is enabled for all IB policies. For example, IB policies that block two users from communicating with each other also restrict these users from seeing each other when using the people picker. Administrators can now choose to disable the user discoverability restriction using Security & Compliance Center PowerShell cmdlet Set-PolicyConfig. For more information, see Manage information barriers policies.
Figure 2: Disable user discoverability restriction by IB
Upgrading to IB v2
Organizations using IB v1 will be eligible to upgrade to IB v2 in the future. For more information about the IB v2 upgrade timeline, see the information barriers roadmap.
present conflicting information, even years after they were first publicly described here. What's the catch?
Allow-Policies don't work as expected. They need explicit concurring (opposite) block polices to work as described above. That renders them more or less useless as they are not really breaking down the complexity of the topic. I am a bit frustrated to be honest.
Now, with the new feature of multi segments, still several questions are left unanswered and even more conflicting documentary comes along. Let's take a look at the example from the official doc for multi segment mode:
North School District's IB policies
The North School District has two schools, School 1 and School 2. The district policy is to allow students and teachers to communicate with each other only if they are both in the same school. For example, a student and teacher that are both in School 1 can communicate, but a student in School 1 cannot communicate with a teacher in School 2. For this scenario, multiple segments are configured to support the following district policy scenarios:
North School District's schools and plan
North School District's has two schools:
Segment Allowed communication Prevented communication
School 1
Students and teachers in School 1
Students and teachers in School 2
School 2
Students and teachers in School 2
Students and teachers in School 1
North School District's defined segments
North School District will use theDepartmentattribute in Azure Active Directory to define segments, as follows:
North School District defines three IB policies, as described in the following table:
Policy Policy Definition
Policy 1: Students and teachers in School 1 can communicate with each other
New-InformationBarrierPolicy -Name School1Policy -SegmentsAllowed 'School1' -AssignedSegment 'School1' -State Active
In this example, the IB policy is calledSchool1Policy. When this policy is active and applied, it will enable students and teachers in School 1 to communicate with each other. This policy is a one-way policy; it won't prevent students and teachers in School 1 from communicating with School 2. For that, Policy 2 is needed.
Policy 2: Students and teachers in School 2 can communicate with each other
New-InformationBarrierPolicy -Name School2Policy -SegmentsAllowed 'School2' -AssignedSegment 'School2' -State Active
In this example, the IB policy is calledSchool2Policy. When this policy is active and applied, it will enable students and teachers in School 2 to communicate with each other.
Policy 3: Teachers in different schools can communicate with each other
New-InformationBarrierPolicy -Name AllTeachersPolicy -SegmentsAllowed 'AllTeachers' -AssignedSegment 'AllTeachers' -State Active
In this case, the IB policy is calledAllTeachersPolicy. When this policy is active and applied, teachers in School 1 and School 2 can communicate with each other.
There's obvioulsy missing the most important part, which is "[...] to allow students and teachers to communicate with each other only if they are both in the same school"
Since I was not sure if I was overseeing something, I fed all the information about IBs I could gather (per official doc) and the example above to ChatGPT and asked if it see's any conflicts here.
That is the answer: "Given these policies, the stated goal of preventing students and teachers in School 1 from communicating with students and teachers from School 2 is not explicitly achieved by the policies provided.
In fact, the policies seem to allow communication between students and teachers within their respective schools (School 1 and School 2) and also allow communication between teachers from different schools (School 1 and School 2). The policies don't explicitly restrict communication between students and teachers of different schools.
To achieve the goal of preventing communication between students and teachers from different schools, additional policies or rules would need to be defined to enforce those restrictions explicitly. As described, the provided policies focus on enabling communication within specific segments but do not impose cross-segment restrictions as per the stated goal."
Sooo... what now? I am confused. The official doc shows clearly, that even the writers of the official doc get confused about the whole configuration concepts of information barriers. We need a clearer documentation about this. I would be happy to help dive into the concept with the developers and fix the documentation for good if possible. This feature is so powerful and highly appreciated- but as of now it's in a pretty messy state and, even more frustrating, no one seems to care.
Multi-Segment support requires Allow policies only.
With IB policies, if one segment (Segment A) can communicate with 3 segments (A, B and C) but B and C are not allowed, the users segment A will only be only able to communicate with their own segment (A) by default. This is because users in Segment A can act as a conduit of information between 2 blocked segments. So, the Segments stamped for all users in Segment A will be A only.
With Multi-Segment if a user is a member of Segments A, B and C, their Sites will be stamped with no segments and set to OwnerModerated Mode. This will allow collaboration between incompatible segments moderated by the site owner.
I'm not sure if you are facing these issues, but I don't think these points are currently documented.
Microsoft
