This content is part of the Essential Guide: The essential guide to PowerShell in Exchange

Outlining RBAC permissions options in Exchange 2013

RBAC's Management Scopes can simplify Exchange setup management tasks and lets admins limit the cmdlets end users can access.

Role Based Access Control, a feature in Exchange Server 2013, gives admins the ability choose the parameters and cmdlets end users can access. The authorization model includes the tasks end users can perform, the permissions to decide who can perform these tasks, and where the tasks can occur within the organization.

Once you've learned the elements that make up Role Based Access Control (RBAC) and how to limit available cmdlets and parameters with custom management roles, you'll need to know how Management Scopes can be used to limit the range of available cmdlets within an organization.

Management Scopes allow admins to limit cmdlets and only allow operation against certain parts of the Exchange organization, mostly from an Active Directory (AD) perspective. Admins can set boundaries at the organizational unit or AD-site level. Boundaries can also limit operation to specific Exchange servers or databases. These are called configuration scopes, which are defined by a Management Scope's Configuration Read Scope and Configuration Write Scope properties. We can also limit operation against specific recipients based on their AD properties. These are called recipient scopes, which are defined by a Management Scope's Recipient Read Scope and Recipient Write Scope properties. A read scope must at least match the boundaries of the write scope; you need to be able to read where you want to write.

Implicit, explicit, relative and custom scopes

If you've made it this far in the RBAC series, you've already created a management role User Photo' which allows assignees to run the *–UserPhoto cmdlets. We used Mail Recipients as its parent when creating this management role. In that process, the newly created management role inherits the scope configuration of the parent management role. These inherited scopes are called implicit scopes, and they are stored in the ImplicitRecipientReadScope, ImplicitRecipientWriteScope, ImplicitConfigReadScope and ImplicitConfigWriteScope properties. Each determines the recipients or configuration-based read and write scopes.

It's important to know the definitions for implicit scopes.

  • Organization: Matches all recipient objects in the Exchange organization.
  • MyGAL: Matches all recipients in the assignee's Global Address List (GAL) and can only be used for read scopes.
  • Self: Matches the current assignee.
  • MyDistributionGroups: Matches distribution groups that the assignee manages.
  • OrganizationConfig: Matches Exchange server or Exchange databases in the current organization.
  • None: Blocks a scope, i.e. no access.

Another type of scope is the explicit scope, which will grant the members of roles with that exclusive scope access to those objects. Explicit scopes are defined at the management role assignment level, causing configured implicit scopes to persist in inherited management roles, while allowing for explicitly configured exceptions.

To create management role assignments -- which operate on specific recipients -- use relative scopes for the assignee. Using the RecipientRelativeWriteScope property, one can allow for operation against the Organization, Self or MyDistributionGroups. For example, if a Management Role allows modification of the UserPhoto property, creating a Management Role Assignment with the RecipientRelativeWriteScope set to "Self" will allow assignees to change their own UserPhoto.

If the predefined implicit scopes don't meet the requirements, create a custom scope for management role assignments. There are different levels to define custom scopes.

  • OU: Use the RecipientOrganizationalUnitScope property.
  • Recipients: Configure the RecipientRestrictionFilter property of a Management Scope and assign it to CustomRecipientWriteScope of the Management Role Assignment. You can use an OPATH filter to target recipients based on department, location etc. In addition, you can use RecipientRoot (canonical form, e.g. to define an alternative starting point in AD. You can find more information on using OPATH filters here.
  • Servers: Configure the ServerRestrictionFilter property of a Management Scope. You can use an OPATH filter to target specific Exchange Servers. Alternatively, you can use the ServerList parameter to directly pick Exchange Servers.
  • Databases: Configure the DatabaseRestrictionFilter property of a Management Scope. You can use an OPATH filter to target specific Exchange databases. Alternatively, you can use the DatabaseList parameter to directly pick databases.

Putting scopes into action

For example, let's define a Management Scope that includes members of a group VIP residing in or below an organizational unit (OU) named 'BR'. Be sure to use the full distinguished name for the group name:

New-ManagementScope –Name 'BR Recipients' –RecipientRoot '' –RecipientRestrictionFilter { MemberOfGroup –eq 'CN=VIP,CN=Users,DC=contoso,DC=com'}

You can also create a scope that includes all configuration objects in a site. Specify the full distinguished name of the AD Site object:

New-ManagementScope –Name 'Site GRU' –ServerRestrictonFilter {ServerSite –eq 'CN=GRU,CN=Sites,CN=Configuration,DC=contoso,DC=com'}

A more basic way to filter is directly specifying server names using DatabaseList or ServerList:

New-ManagementScope –Name 'Servers BR' –ServerList BREX01,BREX02

You can use wildcard matching in OPATH filters:

New-ManagementScope –Name 'BR Databases' –DatabaseRestrictionFilter {Name –like 'BR-*'}

To assign the "BR Recipients" scope to a group named "GlobalPhotoAdmins", use:

New-ManagementRoleAssignment –SecurityGroup 'GlobalPhotoAdmins' –Role 'User Photo' –CustomRecipientWriteScope 'BR Recipients'

This will result in members of GlobalPhotoAdmins being able to use *-UserPhoto cmdlets as granted by assigning the "User Photo" management role. This includes the restriction that they can only do this on members of the VIP group located in or below the top-level BR OU, which the "BR Recipients" Management Scope defines.

We've mentioned exclusive scopes and how they can provide exclusive access to recipients or configuration objects. For example, if you create an exclusive recipient scope for a top-level OU named "BR/Executives," which are members of a group named "VIP," and you use that scope in a management role assignment, all other assignments will be denied access for those recipients.

You create an exclusive scope by specifying the exclusive switch:

New-ManagementScope –Name 'Executive BR Recipients' –RecipientRoot '' –RecipientRestrictionFilter { MemberOfGroup –eq 'CN=VIP,CN=Users,DC=contoso,DC=com'} -Exclusive

And for the purpose of this example, we assign this exclusive Management Scope to a group named "Exec Photo Admins":

New-ManagementRoleAssignment –SecurityGroup 'ExecPhotoAdmins' –Role 'User Photo' –ExclusiveRecipientWriteScope 'Executive BR Recipients'

Only members of ExecPhotoAdmins can exclusively configure mailbox recipients in and below OU=Executives,OU=BR,DC=contoso,DC=com using the options made available to them through User Photo. GlobalPhotoAdmins members can't, although they have these permissions configured on the top-level OU BR and below (Figure 1).

This is an example of a possible way to put Management Scopes into action for your organization.

Keep in mind Management Scopes are static. If you rename properties of the elements you use in your scopes or you relocate objects, you may need to update any related Management Scopes accordingly. For example, you'll need to update after moving an OU or renaming a site object.

About the author:
Michel de Rooij is a consultant and Exchange MVP from the Netherlands. Michel started originally as a developer back in 1994 but quickly switched to infrastructure-related projects and started focusing on Exchange in 2004, covering a number of areas, including migrations, transitions, consolidation and disentanglement. Besides Exchange, Michel's other areas of interest are PowerShell, Active Directory, Lync and messaging in general. Michel is a contributor to The UC Architects podcast and blogs about Exchange and related subjects at

Next Steps

This is part three in a series on Exchange 2013's Role Based Access Control feature.
Part one introduced RBAC and took a brief look at how the feature works.
Part two detailed how to define the commands and tasks end users can access.  

Dig Deeper on Exchange Server setup and troubleshooting