Compliance Boundaries

Page content

Very niche post today. Few will need to delve into Office 365 Compliance Boundaries unless they need to unblock some regulatory compliance requirement. If your in that situation hopefully this will help you.

The scenario is this: you have multiple eDiscovery teams in your organisation. Each eDiscovery team should only see content belonging to users in their own sphere of responsibility.

Example requirement:

  • eDiscovery team ACME should only be able to see content for company ACME

  • eDiscovery team Contoso should only be able to see content for company Contoso

  • eDiscovery team ACME must never collect content from company Contoso

Microsoft documentation about this is here: https://docs.microsoft.com/en-us/microsoft-365/compliance/set-up-compliance-boundaries PowerShell command docs for Policy & Compliance here: https://docs.microsoft.com/en-us/powershell/module/exchange/?view=exchange-ps#policy-and-compliance-ediscovery

Step 1: Pick a user account attribute to group users into ‘agencies’

Your options are:

  • Company
  • CustomAttribute1 - CustomAttribute15
  • Department
  • Office
  • C (Two-letter country code)*

Note *This attribute maps to the CountryOrRegion property that is returned by running the Get-User cmdlet in Exchange Online PowerShell. The cmdlet returns the localized country name, which is translated from the two-letter country code. For more information, see the CountryOrRegion parameter description in the Set-User cmdlet reference article. Although more user attributes are available, particularly for Exchange mailboxes, the attributes listed above are the only ones currently supported by OneDrive.

Using user account attributes really depends on good quality of data in your directory. If it’s patchy for the attribute you indend to use, fix that first. Use something like the following to see how many unique values you have of the property you intend to use. How consistent is account provisioning? How many are just blank?

$allADUsers=get-aduser -all $true -property company
$allADUsers | group-object -property company

Standards, there’s so many to choose from!

Take care that the naming of user account attributes varies between AD, AzureAD and Exchange Online (mailboxes & teams chat). Country for example.

get-aduser someone@companyname.com | format-list        # List AD attributes
get-Azureaduser someone@companyname.com | format-list   # List Azure AD attributes (connection required)
get-user someone@companyname.com | format-list          # List Exchange Online attributes (connection required)

I’m choosing “Company”, in this example.

Step 2: Tell Microsoft which property you intend to use

Microsoft have to do some magic at the backend to ensure the per-user OneDrive my-sites are tagged with the attribute you’re interested in.

Step 3: Create a role group for each agency

This step you need to do manually in https://protection.office.com. There’s no PowerShell module for this. In permissions, select ‘eDiscovery Manager’ role and create two new roles based on this role.

  1. ‘eDiscovery Manager Company is Contoso’

  2. ‘eDiscovery Manager Company not Contoso’

Subsitute with the attribute and value you’re using. In this example I’m choosing Company as the attribute and Toblerone as the value. Since there’s only two Companies in this scenarios we’ll make it a binary one or other choice. Users with Company set to Toblerone and everyone else. After creating these in the portal, check your role groups exist using Security & Compliance PowerShell.

Get-RoleGroup | Sort-Object -Property name | select name
Note: there is a clash for get-rolegroup command. If you connect to ExchangeOnline and S&C at the same time they both have a commandlet with same name and different results/scope. Use the one from S&C only for this.

Step 4: Create a search permissions filter to enforce the compliance boundary

When eDiscovery team staff run searches & exports, their results will be silently trimmed using the extra filters you define here. These filters are connected to the role groups you created in step 3. Members of the role groups will have the filters appened to their searches and exports.

# Make code debuggable
$ErrorActionPreference = "Stop"
Set-StrictMode -Version latest

# Setup pre-requisites
#import-module 'ActiveDirectory' # Get this from Remote Server Admin Tools (RSAT) OS optional feature
install-module 'AzureAD' -scope currentuser
install-module 'ExchangeOnlineManagement' -scope currentuser

# Connect to Azure AD and Security & Compliance
Connect-AzureAD
Connect-IPPSSession

# https://docs.microsoft.com/en-us/microsoft-365/compliance/permissions-filtering-for-content-search?view=o365-worldwide#new-compliancesecurityfilter

# following things can be filtered in exchange:
# https://docs.microsoft.com/en-us/powershell/exchange/recipientfilter-properties?redirectedfrom=MSDN&view=exchange-ps

# Following things can be filtered in SharePoint 
# or a list of searchable site properties, see Overview of crawled and managed properties in SharePoint. Properties marked with a Yes in the Queryable column can be used to create a site or site content filter.
# https://go.microsoft.com/fwlink/p/?LinkId=331599

# Check role group exists, create filters, link filters to role groups. Note only filtering mailboxes (and Teams chat) here.
$roleGroup=Get-RoleGroup -Identity 'eDiscovery Manager Company is Contoso'
$filterslist="Mailbox_Company  -eq 'Contoso'" # search results with Contoso company only
New-ComplianceSecurityFilter -FilterName ediscoContosoOnly -Users $roleGroup.name -Filters $filterslist  -Action All

$roleGroup=Get-RoleGroup -Identity 'eDiscovery Manager Company is not Contoso'
$filterslist="Mailbox_Company  -ne 'Contoso'" # search results without Contoso company only
New-ComplianceSecurityFilter -FilterName ediscoNotContosoOnly -Users $roleGroup.name -Filters $filterslist  -Action All

# See the resulting filters in place
get-ComplianceSecurityFilter

# To clean up
#Remove-ComplianceSecurityFilter -FilterName ediscoContosoOnly
#Remove-ComplianceSecurityFilter -FilterName ediscoNotContosoOnly

Step 5: Test your requirements have been met

Finally test (demos.microsoft.com is great for this) eDiscover Managers in one role group should be able to collect data from the wrong company.

In this example the requirements were:

  • eDiscovery team ACME should only be able to see content for company ACME eDisco admins for company ACME are moved to ‘eDiscovery Manager Company not Contoso’ role

  • eDiscovery team Contoso should only be able to see content for company Contoso eDisco admins for company Contoso are moved to ‘eDiscovery Manager Company Contoso’ role

  • eDiscovery team ACME must never collect content from company Contoso Using an ACME account in the first ‘eDiscovery Manager Company not Contoso’ role, test that eDiscovery searches return results from non-Contoso sources/users only.


Find more IT Infrastructure tips at blog.alexmags.com