Using RBAC to restrict Discovery Searches

Introduction

eDiscovery is a powerful feature available in Microsoft Exchange. It’s used by eDiscovery Managers for performing discovery searches across all mailboxes in the organization and is very important for the purpose of the Compliance and Legal issues.

By default, the Discovery Management role group is created when the first Microsoft Exchange Server is installed. As most of us know, this role group is responsible for allowing access to administrators to perform eDiscovery searches, and because it’s a Default role group, we can’t restrict the scope of the role group to specific mailboxes. Members of this role group can search all mailboxes across the organization.

So, what do you do when you get a request to restrict the eDiscovery search to a specific subset of mailboxes based on company or department? Is it even possible?

The answer to this is yes! We can utilize the power of Role Based Access Control (RBAC) to limit the search to a subset of mailboxes.

Note: The only RecipientRestrictionFilter in Microsoft Exchange Server 2013 and Exchange Online that is supported for a custom eDiscovery scope is the memberofGroup property for user mailboxes.

This blog post discusses such a scenario where the search is restricted to a specific department. For this to be supported in Microsoft Exchange 2013, we need to follow a common set of rules when creating custom scopes for eDiscovery.

Restricting eDiscovery to a specific department using a RecipientFilter

John works for a company named TailSpin Toys. John has been given a new task within the company. John will be working as eDiscovery Manager within the company and will perform eDiscovery searches for a specific set of mailboxes that reside in the Accounting department. The Microsoft Exchange administrator will need to assign necessary permissions to John BUT will have to ensure John can’t perform eDiscovery searches on mailboxes in any department other than Accounting. In this scenario, we will restrict the scope of the search to a specific department named Accounting.

To implement this scenario we will walk through the following steps.

Create a distribution group for the Accounting department and add the required set of user mailboxes as members of the distribution group.

Define a custom scope to include only the users who are members of the Accounting department distribution group created to limit the scope of the mailboxes that can be searched. This is achieved by using the RecipientRestrictionFilter and the DistributionListMembership as criteria for the new scope.

Create a new role group, and assign the new custom scope, add the “Mailbox Search” and “Legal Hold” roles, and then add John as member of the role group so he will be the dedicated eDiscovery manager for the Accounting department

Create a new dedicated discovery mailbox for the eDiscovery searches to be saved and assign full access permissions to John

1. Create and configure the distribution group for the Accounting department

As per the scenario, the Exchange administrator creates Distribution Group named eDiscovery Accounting Users by running the following command.

The previous command creates a variable that contains all user mailboxes that have the value Accounting for the Department property in their user account. The following command will add the users to the Accounting distribution group.

The Distribution group has to be a Mail Enabled Universal Distribution Group and can be created using the Exchange Admin Center or the Exchange Management Shell.

The Distribution group created can have more than one Owner.

Ensure that the moderation is enabled and the distribution group is hidden from the global address list (GAL).

Also, members shouldn’t be automatically added to the distribution group and they shouldn’t be able to leave the group automatically. Check the properties of the distribution group to confirm these requirements by running the following command.

2. Create a Custom management scope using the RecipientRestrictionFilter

Custom scopes are needed when neither the implicit write scope nor the predefined relative scopes meet the needs of your business. Custom scopes enable you to define, at a granular level, the scope to which your management role will be applied.

After the user mailboxes are added to the distribution group eDiscovery Accounting Users, the next step is to create a Custom Management Scope.

Create a custom management scope

Run the following command to save the properties of the eDiscovery Accounting Users group to a variable, which is used in the next command.

$DG = Get-DistributionGroup -Identity "eDiscovery Accounting Users"

The next step is to create a Custom scope where the RecipientRestrictionFilter is set to the distribution group created in Step1. After the Scope is created, it will be assigned to the Role Group that is created in a later step.

After the Management Scope is created, you can verify the RecipientFilterby running the following command. This recipient filter will be used to define the scope of the eDiscovery search operation.

Note:

The only RecipientRestrictionFilter in Microsoft Exchange Server 2013 and Exchange Online that is supported for a custom eDiscovery scope is the memberofGroup property for the user mailboxes.

The above restriction only applies for custom scopes for eDiscovery.

3. Create a new role group

In this step, you will create a new management role group and assign it to the custom management scope named "Accounting Users eDiscovery Scope" that was created in previous step. To do this run the following command.

The new role group will be created under Microsoft Exchange Security Groupscontainer and will have the "Mailbox Search" and "Legal Hold"roles associated with it. The eDiscovery search scope will be restricted to the members of the eDiscovery Accounting Users distribution group, which is the RecipientFilter for the scope. John is added as member of the role group and will have the permissions to perform required administrative tasks.

If you want to add additional members to the role group, you can run the following command.

Note: It's important not to add unmonitored or unauthorized users to the Discovery Management role group as they will get access to discovery mailboxes, and they can search mailboxes across the entire organization.

To check the RoleAssignmentsassociated with the "Accounting Users eDiscovery Managers" run the following command.

Get-RoleGroup "Accounting Users eDiscovery Managers" | FL

Run the following command to view the CustomRecipientWriteScope and the RecipientReadScope associated with the role.

The previous command shows the roles being assigned to the “Accounting Users eDiscovery Managers” role group and also tells us that the RoleGroupType is set to Standard and the RecipientReadScope is set to Organization, which means all mailboxes across the Organization will be only visible to all the eDiscovery Managers. The Search will fail for mailboxes searched outside the scope when accessed by users who belong to Accounting Users eDiscovery Managerswho belong to specific role group and have CustomRecipientWriteScopedefined for certain subset of mailboxes.

Note: By default, all the mailboxes will be visible to eDiscovery Managers and the parameter RecipientReadScopecannot be overridden to restrict the same.

4. Create a dedicated discovery mailbox for the Accounting department

To create a discovery mailbox to store the search results of eDiscovery searches of mailboxes in the Accounting department, run the following command.

The discovery mailbox created will have the associated user account disabled.

If you want to copy the search results from a search that uses the custom scope, the discovery mailbox has to be a member of the "eDiscovery Accounting Users" distribution group, which was used to create the scope. Run the following command to add the discovery mailbox as a member of the distribution group.

After the permissions have replicated, John can access the discovery mailbox.

Points to remember

The reason for creating a discovery mailbox for the dedicated departments is to avoid copying search results to the default discovery mailbox, which can be accessed by other eDiscovery Managers.

Creating additional discovery mailboxes for a department to copy the search results reduces the risk of data leak. In our scenario, we only provide access to the required eDiscovery manager who will be performing the eDiscovery searches for the Accounting department.

Also for mailboxes such as the discovery mailbox, which may contain sensitive information, consider enabling mailbox audit logging for mailbox owner actions such as message deletion. It’s also a good idea to enable mailbox auditing for user mailboxes that will be searched.

The EAC will list the discovery mailbox only when the search results are to be copied to it. This is default behavior.

Remember that mailbox audit logging for discovery mailboxes can only be managed using the Exchange Management Shell.

Test the eDiscovery operation for the Role Group

At this point, John performs a discovery search, choosing some of the mailboxes from Accounting and an appropriate date range and is able to get expected results. For more information on how to do a discovery search, please go here

What happens when an eDiscovery manager searches mailboxes outside the custom scope

If John tries to perform a search on mailboxes outside the custom scope, the search will return the error shown below. This happens because the RecipientRestrictionFilter applied to the scope and in turn applied to the role group will check the MemberOfGroup property. When it finds the MemberOfGroupvalue of the user mailbox doesn’t match distinguished name of the eDiscovery Accounting Users distribution group, it confirms the user mailbox isn’t within the custom scope.

Even though you grant Mailbox Search role explicitly to the Role Group you won’t be able to search mailboxes outside the scope

Administrator Audit Logging and eDiscovery

By default the Administrator audit logging is enabled in the new installations of Microsoft Exchange 2013 and will capture the all the Cmdlets run directly in the Exchange Management Shell are audited. In addition, operations performed using the EAC are also logged because those operations run Cmdlets in the background. This will also include the eDiscovery Cmdlets run in the environment. The administrator needs to be member of Discovery Management Group in order to have access to MailboxSearchCmdlets.

The Organization Managementrole group doesn't, by default, enable the discovery search feature for users or universal security groups (USGs) that are members of that role group. Members of the Organization Management role group must either be made members of this role group, or the Mailbox Search role listed later in this topic must be manually assigned to the Organization Management role group.

The audit log reports can be exported by the administrator using the EAC to track changes in your organization. Also, the administrator can run the In-Place eDiscovery & Hold report for specific date to check for the searches performed on that specific day. It will provide report for any modifications done to the search.

The administrator audit log will keep track of Cmdlets run in the environment and this way, any unauthorized access can be tracked down.

Conclusion

The scenario discussed in this blog post is always an available option for restricting eDiscovery searches based on department or company. The only requirement is to use a distribution group for the subset of mailboxes on for you want to restrict eDiscovery. The only property on a user mailbox that you can use to create a recipient filter for a custom scope is distribution group membership (the actual property name is MemberOfGroup). If you use other properties, such as CustomAttribute, Department, or PostalCode, the search method will be considered unsupported.

So if you want to do a search for mailboxes across departments or separate companies you will have to manually add the users to the distribution group or usePowerShellto add users in bulk to a specific distribution group based on department or company.

Note:

Dynamic distribution groups won’t work for creating a custom scope for eDiscovery.

Nesting of the Distribution groups in the primary distribution group won’t work because the scope will only look at the MemberOfGroup. Nested groups will have user accounts added to it, but will have a different value for the property MemberOfGroup. To work around this, administrators can create single custom scope with multiple distribution groups.

You can still create a Role Group with the Organizational Unit Parameter to limit the role group and associate with roles to only specific OU, but this method won't be supported for custom eDiscovery.

eDiscovery searches performed by using a custom scope will be visible to other eDiscovery managers. The search can be deleted by unauthorized eDiscovery managers BUT that action will be captured in the administrator audit log.

In the above blog I have tried to discuss and walk you through the options related to the restricting the eDiscovery to discovery managers as per the business needs using Role Bases Access Control

I would like to thank Mark Johnson, Bharat Suneja, Nino Bilic, Jennifer Gagnon & Quentin Christensen for their help in validating the method described in the blog post!

Special Thanks to Ben Winzenz, Chris Pollitt, Matthew Byrd, Charlotte Raymundo for their contributions while this blog post was being written.

Grzegorz, that’s what they mean by MemberOfGroup being the only supported method. You can create scopes based on other criteria, but those will fail on one on more of the common eDiscovery tasks: Estimate results, Preview results, Export results, Copy
results.

The most acceptable ‘replacement’ I’ve found is a filter based on Emailaddresses or displayName. For those, it seems that only the Preview results task fails, and I can live with that. If you add CustomattributeX, copying results seems to fail (or maybe I forgot
to properly configure the Discovery mailbox). Other attributes seem to cause even more trouble.

I tried doing something similar (restricting mailbox search to specific people/group) recently and results were not good.
From my test these features will not work in this scenario: preview search results (shows no results) and download search to PST files (this on fails with “object reference not set to an instance of an object” error).
I was actually preparing MS support case for this.
Can you confirm ?

@ Grzegorz Wierzbicki: The Preview search results and export to PST files will work in this scenario. This has been tested! it seems there is some other issue in your test environment which could be contributing to the error.