Get started with information barriers

This article describes how to configure information barriers (IB) policies in your organization. Several steps are involved, so make sure you review the entire process before you begin configuring IB policies.

You'll configure IB in your organization using the Microsoft Purview portal, the Microsoft Purview compliance portal, or by using Office 365 Security and Compliance PowerShell. For organizations configuring IB for the first time, we recommend using the Information barriers solution in the compliance portal. If you're managing an existing IB configuration and you're comfortable using PowerShell, you still have this option.

For more information about IB scenarios and features, see Learn about information barriers.

Required subscriptions and permissions

Before you get started with IB, you should confirm your Microsoft 365 subscription and any add-ons. To access and use IB, your organization must have supporting subscriptions or add-ons. For more information, see the subscription requirements for information barriers.

To manage IB policies, you must be assigned one of the following roles:

• Microsoft 365 global administrator
• Office 365 global administrator
• Compliance administrator
• IB Compliance Management

Configuration concepts

When you configure IB, you'll work with several objects and concepts.

• User account attributes are defined in Microsoft Entra ID (or Exchange Online). These attributes can include department, job title, location, team name, and other job profile details. You'll assign users or groups to segments with these attributes.

• Segments are sets of groups or users that are defined in the Microsoft Purview portal, the compliance portal, or by using PowerShell that uses selected group or user account attributes.

  Your organization can have up to 5,000 segments and users can be assigned to a maximum of 10 segments. See the list of IB supported attributes for details.

  Important

  Support for 5,000 segments and assigning users to multiple segments is only available when your organization isn't in Legacy mode. Assigning users to multiple segments requires additional actions to change the information barriers mode for your organization. For more information, see Use multi-segment support in information barriers for details.
  
  For organizations in Legacy mode, the maximum number of segments supported is 250 and users are restricted to being assigned to only one segment. Organizations in Legacy mode will be eligible to upgrade to the newest version of information barriers in the future. For more information, see the information barriers roadmap.

• IB policies determine communication limits or restrictions. When you define IB policies, you choose from two kinds of policies:

  • Block policies prevent one segment from communicating with another segment.

  • Allow policies allow one segment to communicate with only certain other segments.

    Note

    For organizations in Legacy mode: Non-IB groups and users will not be visible to users included in IB segments and policies for allow policies. If you need non-IB groups and users to be visible to users included in IB segments and policies, you must use block policies.
    
    For organizations in SingleSegment or MultiSegment mode: Non-IB groups and users will be visible to users included in IB segments and policies.
    
    To verify your IB mode, see Check the IB mode for your organization.

• Policy application is done after all IB policies are defined, and you're ready to apply them in your organization.

• Visibility of non-IB users and groups: Non-IB users and groups are users and groups excluded from IB segments and policies. Depending on when you configure IB policies in your organization and the type of IB policies (block or allow), the behavior for these users and group will differ in Microsoft Teams, SharePoint, OneDrive, and in your global address list.

  • For organizations in Legacy mode: For users defined in allow policies, non-IB groups and users won't be visible to users included in IB segments and policies. For users defined in block policies, non-IB groups and users will be visible to users included in IB segments and policies.
  • For organizations in SingleSegment or MultiSegment mode: Non-IB groups and users will be visible to users included in IB segments and policies.

• Group support. Only Modern Groups are currently supported in IB and Distribution Lists/Security Groups are treated as non-IB groups.

• Hidden/disabled user and guest accounts. For hidden/disabled user and guest accounts in your organization, the HiddenFromAddressListEnabled parameter is automatically set to True when user accounts are hidden or disabled, or when a guest is created. When the organization mode is Legacy for IB-enabled organizations, these accounts are prevented from communicating with all other user accounts. Administrators can disable this default behavior by manually setting the HiddenFromAddressListEnabled parameter to False.

Configuration overview

Step 1: Make sure prerequisites are met

In addition to the required subscriptions and permissions, make sure that the following requirements are met before configuring IB:

• Directory data: Make sure that your organization's structure is reflected in directory data. To take this action, make sure that user account attributes (such as group membership, department name, etc.) are populated correctly in Microsoft Entra ID (or Exchange Online). To learn more, see the following resources:

  • Attributes for information barriers policies

  • Add or update a user's profile information using Microsoft Entra ID

  • Configure user account properties with Office 365 PowerShell

• Scoped directory search: Before you define your organization's first IB policy, you must enable scoped directory search in Microsoft Teams. Wait at least 24 hours after enabling scoped directory search before you set up or define IB policies.

• Verify audit logging is enabled: In order to look up the status of an IB policy application, audit logging must be turned on. Auditing is enabled for Microsoft 365 organizations by default. Some organizations may have disabled auditing for specific reasons. If auditing is disabled for your organization, it might be because another administrator has turned it off. We recommend confirming that it's OK to turn auditing back on when completing this step. For more information, see Turn the audit log search on or off.

• Check the IB mode for your organization: Support for multiple segments, people discoverability options, Exchange ABPs, and other features is determined by the IB mode for your organization. To verify the IB mode for your organization, see Check the IB mode for your organization.

• Remove existing Exchange Online address book policies (optional):

  • For organizations in Legacy mode: Before you define and apply IB policies, you must remove all existing Exchange Online address book policies in your organization. IB policies are based on address book policies and existing ABPs policies aren't compatible with the ABPs created by IB. To remove your existing address book policies, see Remove an address book policy in Exchange Online. For more information about IB policies and Exchange Online, see Information barriers and Exchange Online.
  • For organizations in SingleSegment or MultiSegment mode: Information barriers is no longer based on Exchange Online Address Book Policies (ABPs). Organizations using ABPs won't have any impact to the existing ABPs when enabling information barriers.

• Manage using PowerShell (optional): IB segments and policies can be defined and managed in the compliance portal, but you can also use the Office 365 Security & Compliance PowerShell if preferred or needed. Although several examples are provided in this article, you'll need to be familiar with PowerShell cmdlets and parameters if you choose to use PowerShell to configure and manage IB segments and policies. You'll also need the Microsoft Graph PowerShell SDK if you choose this configuration option.

  • Connect to Security & Compliance PowerShell

  • Install the Microsoft Graph PowerShell SDK

When all the prerequisites are met, proceed to the next step.

Step 2: Segment users in your organization

In this step, you'll determine what IB policies are needed, make a list of segments to define, and define your segments. Defining segments doesn't affect users, it just sets the stage for IB policies to be defined and then applied.

Determine what policies are needed

Considering the needs of your organization, determine the groups within your organization who will need IB policies. Ask yourself the following questions:

• Are there internal, legal, or industry regulations that require the restriction of communication and collaboration between groups and users in your organization?
• Are there any groups or users who should be prevented from communicating with another group of users?
• Are there any groups or users that should be allowed to communicate only with one or two other groups of users?

Think about the policies you need as belonging to one of two types:

• Block policies prevent one group from communicating with another group.
• Allow policies allow a group to communicate with only specific groups.

When you have your initial list of needed groups and policies, proceed to identify the segments you'll need for the IB policies.

Identify segments

In addition to your initial list of policies, make a list of segments for your organization. Users who will be included in IB policies should belong to at least one segment. Users can be assigned to multiple segments if needed. You can have up to 5,000 segments in your organization and each segment can have only one IB policy applied.

Determine which attributes in your organization's directory data you'll use to define segments. You can use Department, MemberOf, or any of the supported IB attributes. Make sure that you have values in the attribute you select for users. For more information, see the supported attributes for IB.

Enable multiple segment support for users (optional)

Support for assigning users to multiple segments is only available when your organization isn't in Legacy mode. If you want to support assigning users to multiple segments, see Use multi-segment support in information barriers.

Users are restricted to being assigned to only one segment for organizations in Legacy mode. Organizations in Legacy mode will be eligible to upgrade to the newest version of information barriers in the future. For more information, see the information barriers roadmap.

Define segments using the portals

Select the appropriate tab for the portal you're using. To learn more about the Microsoft Purview portal, see Microsoft Purview portal. To learn more about the Compliance portal, see Microsoft Purview compliance portal.

Define segments using PowerShell

To define segments with PowerShell, complete the following steps:

1. Use the New-OrganizationSegment cmdlet with the UserGroupFilter parameter that corresponds to the attribute you want to use.

   Syntax	Example
   New-OrganizationSegment -Name "segmentname" -UserGroupFilter "attribute -eq 'attributevalue'"	New-OrganizationSegment -Name "HR" -UserGroupFilter "Department -eq 'HR'" In this example, a segment called HR is defined using HR, a value in the Department attribute. The -eq portion of the cmdlet refers to "equals." (Alternately, you can use -ne to mean "not equals". See Using "equals" and "not equals" in segment definitions.)

   After you run each cmdlet, you should see a list of details about the new segment. Details include the segment's type, who created or last modified it, and so on.

2. Repeat this process for each segment you want to define.

After you've defined your segments, proceed to Step 3: Create IB policies.

Using "equals" and "not equals" in PowerShell segment definitions

In the following example, we're configuring IB segments using PowerShell and defining a segment such that 'Department equals HR'.

You can also define segments using a "not equals" parameter, denoted as -ne, as shown in the following table:

In addition to defining segments using "equals" or "not equals", you can define a segment using both "equals" and "not equals" parameters. You can also define complex group filters using logical AND and OR operators.

Step 3: Create IB policies

When you create your IB policies, you'll determine whether you need to prevent communications between certain segments or limit communications to certain segments. Ideally, you'll use the minimum number of IB policies to ensure your organization is compliant with internal, legal, and industry requirements. You can use the Microsoft Purview portal, the compliance portal, or PowerShell to create and apply IB policies.

With your list of user segments and the IB policies you want to define, select a scenario, and then follow the steps.

• Scenario 1: Block communications between segments
• Scenario 2: Allow a segment to communicate only with one other segment

Scenario 1: Block communications between segments

When you want to block segments from communicating with each other, you define two policies: one for each direction. Each policy blocks communication in one direction only.

For example, suppose you want to block communications between Segment A and Segment B. In this case, you'd define two policies:

• One policy preventing Segment A from communicating with Segment B
• A second policy to prevent Segment B from communicating with Segment A

Create policies using the portals for Scenario 1

Select the appropriate tab for the portal you're using. To learn more about the Microsoft Purview portal, see Microsoft Purview portal. To learn more about the Compliance portal, see Microsoft Purview compliance portal.

Create policies using PowerShell for Scenario 1

To define policies with PowerShell, complete the following steps:

1. To define your first blocking policy, use the New-InformationBarrierPolicy cmdlet with the SegmentsBlocked parameter.

   Syntax	Example
   New-InformationBarrierPolicy -Name "policyname" -AssignedSegment "segmentAname" -SegmentsBlocked "segmentBname"	New-InformationBarrierPolicy -Name "Sales-Research" -AssignedSegment "Sales" -SegmentsBlocked "Research" -State Inactive In this example, we defined a policy called Sales-Research for a segment called Sales. When active and applied, this policy prevents users in Sales from communicating with users in a segment called Research.

2. To define your second blocking segment, use the New-InformationBarrierPolicy cmdlet with the SegmentsBlocked parameter again, this time with the segments reversed.

   Example	Note
   New-InformationBarrierPolicy -Name "Research-Sales" -AssignedSegment "Research" -SegmentsBlocked "Sales" -State Inactive	In this example, we defined a policy called Research-Sales to prevent Research from communicating with Sales.

3. Proceed to one of the following actions:

   • (If needed) Define a policy to allow a segment to communicate only with one other segment
   • (After all your policies are defined) Apply IB policies

Scenario 2: Allow a segment to communicate only with one other segment

When you want to allow a segment to communicate with only one other segment, you define two policies: one for each direction. Each policy allows communication in one direction only.

In this example, you'd define two policies:

• One policy allows Segment A to communicate with Segment B
• A second policy to allow Segment B to communicate with Segment A

Create policies using the portals for Scenario 2

Select the appropriate tab for the portal you're using. To learn more about the Microsoft Purview portal, see Microsoft Purview portal. To learn more about the Compliance portal, see Microsoft Purview compliance portal.

Create a policy using PowerShell for Scenario 2

To define policies with PowerShell, complete the following steps:

1. To allow one segment to communicate with the other segment, use the New-InformationBarrierPolicy cmdlet with the SegmentsAllowed parameter.

   Syntax

   Example

   New-InformationBarrierPolicy -Name "policyname" -AssignedSegment "segmentAname" -SegmentsAllowed "segmentBname","segment1name"

   New-InformationBarrierPolicy -Name "Manufacturing-HR" -AssignedSegment "Manufacturing" -SegmentsAllowed "HR","Manufacturing" -State Inactive In this example, we defined a policy called Manufacturing-HR for a segment called Manufacturing. When active and applied, this policy allows users in Manufacturing to communicate only with users in a segment called HR. In this case, Manufacturing can't communicate with users who aren't part of HR.

   If needed, you can specify multiple segments with this cmdlet, as shown in the following example.

   Syntax	Example
   New-InformationBarrierPolicy -Name "policyname" -AssignedSegment "segmentAname" -SegmentsAllowed "segmentBname", "segmentCname","segmentDname"	New-InformationBarrierPolicy -Name "Research-HRManufacturing" -AssignedSegment "Research" -SegmentsAllowed "HR","Manufacturing","Research" -State Inactive In this example, we defined a policy that allows the Research segment to communicate with only HR and Manufacturing.

   Repeat this step for each policy you want to define to allow specific segments to communicate with only certain other specific segments.

2. To define your second allowing segment, use the New-InformationBarrierPolicy cmdlet with the SegmentsAllowed parameter again, this time with the segments reversed.

   Example	Note
   New-InformationBarrierPolicy -Name "Research-Sales" -AssignedSegment "Research" -SegmentsAllowed "Sales" -State Inactive	In this example, we defined a policy called Research-Sales to allow Research to communicate with Sales.

3. Proceed to one of the following actions:

   • (If needed) Define a policy to block communications between segments
   • (After all your policies are defined) Apply IB policies

Step 4: Apply IB policies

IB policies aren't in effect until you set them to active status and apply the policies.

Apply policies using the portals

Select the appropriate tab for the portal you're using. To learn more about the Microsoft Purview portal, see Microsoft Purview portal. To learn more about the Compliance portal, see Microsoft Purview compliance portal.

Apply policies using PowerShell

To apply policies using PowerShell, complete the following steps:

1. Use the Get-InformationBarrierPolicy cmdlet to see a list of policies that have been defined. Note the status and identity (GUID) of each policy.

   Syntax: Get-InformationBarrierPolicy

2. To set a policy to active status, use the Set-InformationBarrierPolicy cmdlet with an Identity parameter, and the State parameter set to Active.

   Syntax	Example
   Set-InformationBarrierPolicy -Identity GUID -State Active	Set-InformationBarrierPolicy -Identity 43c37853-ea10-4b90-a23d-ab8c93772471 -State Active In this example, we set an IB policy that has the GUID 43c37853-ea10-4b90-a23d-ab8c93772471 to active status.

   Repeat this step as appropriate for each policy.

3. When you have finished setting your IB policies to active status, use the Start-InformationBarrierPoliciesApplication cmdlet in Security & Compliance PowerShell.

   Syntax: Start-InformationBarrierPoliciesApplication

   After you run Start-InformationBarrierPoliciesApplication, allow 30 minutes for the system to start applying the policies. The system applies policies user by user. The system processes about 5,000 user accounts per hour.

View status of user accounts, segments, policies, or policy application

With PowerShell, you can view status of user accounts, segments, policies, and policy application, as listed in the following table.

What if I need to remove or change policies?

Resources are available to help you manage your IB policies.

• To edit, stop, or remove IB policies, see Manage information barriers policies.
• If something goes wrong with IB, see Troubleshooting information barriers.

Step 5: Configuration for information barriers on SharePoint and OneDrive

If you're configuring IB for SharePoint and OneDrive, you'll need to enable IB on these services. You'll also need to enable IB on these services if you're configuring IB for Microsoft Teams. When a team is created in Microsoft Teams team, a SharePoint site is automatically created and associated with Microsoft Teams for the files experience. IB policies aren't honored on this new SharePoint site and files by default.

To enable IB in SharePoint and OneDrive, follow the guidance and steps in the Use information barriers with SharePoint article.

Step 6: Information barriers modes (optional)

Modes can help strengthen access, sharing, and membership of a Microsoft 365 resource based on the resource's IB mode. Modes are supported on Microsoft 365 Groups, Microsoft Teams, OneDrive, and SharePoint sites and are automatically enabled in your new or existing IB configuration.

The following IB modes are supported on Microsoft 365 resources:

Implicit mode updates

Depending on when you've enable IB in your organization, your organization will be in either Legacy, SingleSegment, or MultiSegment organization mode. To verify your mode, see Check the IB mode for your organization.

If your organization is in SingleSegment or MultiSegment mode and the information barriers mode of the Teams group is Implicit, the Teams-connected groups/sites won't have any segments associated with it.

For more information about IB modes and how they're configured across services, see the following articles:

• Information barriers modes and Microsoft Teams
• Information barriers modes and OneDrive
• Information barriers modes and SharePoint

Step 7: Configure user discoverability for information barriers (optional)

Information barriers policies allow administrators to enable or disable search restrictions in the people picker. By default, the people picker restriction is enabled for IB policies. For example, IB policies that block two specific users from communication can also restrict the users from seeing each other when using the people picker.

To disable the people picker search restriction using PowerShell, complete the following steps:

1. Use the Set-PolicyConfig cmdlet to disable the people picker restriction:

Set-PolicyConfig -InformationBarrierPeopleSearchRestriction 'Disabled'

Example scenario: Contoso's departments, segments, and policies

To see how an organization might approach defining segments and policies, consider the following example scenario.

Contoso's departments and plan

Contoso has five departments: HR, Sales, Marketing, Research, and Manufacturing. In order to remain compliant with industry regulations, users in some departments aren't supposed to communicate with other departments, as listed in the following table:

For this structure, Contoso's plan includes three IB policies:

1. An IB policy designed to prevent Sales from communicating with Research
2. Another IB policy to prevent Research from communicating with Sales.
3. An IB policy designed to allow Manufacturing to communicate with HR and Marketing only.

For this scenario, it's not necessary to define IB policies for HR or Marketing.

Contoso's defined segments

Contoso will use the Department attribute in Microsoft Entra ID to define segments, as follows:

With the segments defined, Contoso proceeds to define the IB policies.

Contoso's IB policies

Contoso defines three IB policies, as described in the following table:

With segments and policies defined, Contoso applies the policies by running the Start-InformationBarrierPoliciesApplication cmdlet.

When the cmdlet finishes, Contoso is compliant with industry requirements.

Resources

• Learn about information barriers
• Use multi-segment support in information barriers
• Learn more about information barriers in Microsoft Teams
• Learn more about information barriers in SharePoint Online
• Learn more about information barriers in OneDrive