As an Exchange 2013 or 2016 sever administrator, you most probably work on different roles that allow you to grant particular users with certain access rights. In this article, you will find out what is the idea of Role Based Access Control in Exchange 2013/2016, how you can manage this model and use it in real life while delegating permissions.

What is the idea of RBAC?

RBAC, short for Role Based Access Control, is a model used to delegate permissions in the Exchange Server environment. It was introduced together with Exchange 2010 and then developed in Exchange 2013. RBAC is used when there is a need for providing a user or a group of users with specific administrative rights so that they can perform certain tasks, e.g. search through mailboxes of other employees in order to retrieve deleted emails. This model is also useful when we want to separate the Domain Admin’s rights from the rights that allow for managing the entire Exchange organization. At this point, it is worth mentioning that quite a common mistake made while assigning permissions to a newly employed administrator is adding them to the Organization Managementrole which allows them to do almost anything with Exchange objects.

To make a long story short, Role Based Access Control model brings:

• Cohesive model to delegate permissions
• A simplified way of granting, removing or auditing permissions
• An easy way of grating more specific rights (e.g. permissions for executing certain cmdlets)

RBAC is based on already created administrative roles (Admin Roles) with assigned sets of permissions in form of Management Roles, Scopes and Members. In the screenshot below, you can see Admin Roles (1), and assigned to them Management Roles (2). Additionally, you can see what the scope for selected Admin Roles (3) is and what members (4) include.

You can use Exchange Management Shell (EMS) to view all Admin Roles by executing this cmdlet:

Get-RoleGroup

The screenshot below shows the result of this command.

Let’s take a closer look at Admin Roles’ key components now, namely Management Role, Scope, Members and Management Role Assignment.

Management Role

Management Role is a set of permissions that allow to perform certain administrative tasks (e.g. monitor the Exchange organization or administrate email queues) defined by particular cmdlets added to this role. In other words, each Management Role is a set of cmdlets that can be executed by a certain user or group of users with reference to particular properties, e.g. all Management Roles can be viewed in EMS by using this command:

Get-ManagementRole

To view all cmdlets that are assigned to this role along with their properties you need to type:

Get-ManagementRoleEntry ‘name_ManagementRole\*’

For example, to view cmdlets and properties assigned to a Management Role called ‘Send Connectors’ you need to use:

Get-ManagementRoleEntry ‘Send Connectors\*’

The result is presented below:

Taking into account the fact that built-in Management Roles do not exhaust all the possible scenarios, you have a possibility to create your own, unusual Management Roles which will only contain the set of permissions you need. Additionally, it is good to know that:

• A non-standard Management Role can be a child role of an already existing Management Role
• A Management Role that is a child role cannot consist of more permissions than the parent role
• Each Admin Role is actually the set of Management Roles assigned to a user or a group of users

Scopes

When you create a new Management Role or edit an existing one, you need to know what the scope of influence/impact of this role is (it is separate for writing and for reading permissions). It is worth noticing that permissions assigned in RBAC do not have to cover all the objects, servers or databases of the Exchange organization but can refer to only filtered objects such as organization units in Active Directory, containers, groups of users and other AD or Exchange objects.

Each Management Role built on the basis of an already existing role inherits the scope of influence from that parent role unless you decide to modify that scope. In order to display the scope of impact of built-in Management Roles you need to execute this cmdlet in EMS:

Get-Management Role | fl *scope*

In the screenshot above you can see:

ImplicitRecipientRead/WriteScope – It refers to recipient objects that can be viewed or modified in Active Directory by a user assigned to the Management Role.

ImplicitConfigRead/WriteScope – This entry refers to a scope of configuration objects in the Exchange organization such as servers or databases that the user assigned to that Management Role can read and modify.

A few types of default scopes can be distinguished:

• Organization – if the user is included in ImplicitRecipientReadScope, it means that they can read recipient objects for entire Exchange organization. On the other hand, if the Organization is included in ImplicitRecipientWriteScope then the user can create or modify recipient objects for the Exchange organization.
• MyGAL – if MyGAL is present in ImplicitRecipientReadScope or ImplicitRecipientWriteScope, the user who is assigned to this role can view objects of recipients included in the user’s current GAL (Global Address List).
• Self – if it is present in ImplicitRecipientReadScope, the user assigned to the role can read only properties of the user’s mailbox, but when it is in ImplicitRecipientWriteScope the user can modify the properties of that mailbox.
• MyDistributionGroups – when this scope is present in ImplicitRecipientReadScope it is possible for a user with this permission to view user’s own distribution list objects, but when MyDistributionGroups is present in ImplicitRecipientWriteScope then properties of distribution list objects can be created or modified by the current user.
• OrganizationConfig – if it is present in ImplicitRecipientReadScope the user can view server or database configuration for the Exchange organization and when it is in ImplicitRecipientWriteScope, it is possible to create and modify server or database configuration across the Exchange organization.
• None – once None has been added to the scope, the scope is excluded from the role. It means that if None is present in ImplicitRecipientWriteScope the user cannot modify recipient objects in the Exchange organization.

Despite the scopes presented above, there is also a possibility of creating our own scopes (custom scopes) which can be adjusted to meet your own business needs. Let’s take a look at an example cmdlet which allows to create a non-standard scope which is 2nd Level Support:

New-ManagementScope –name ‘2nd Level Support’ –RecipientRestrictionFilter {memberofgroup –eq ‘cn=2nd Level Support,ou=Security Groups,dc=domainA,dc=lab’}

Members

When you create a new Admin Role, by using EAC (Exchange Admin Center) or executing the New-RoleGroupcmdlet, in fact you create an AD security group of the Universal type. After it has been created, it can be found in Active Directory in a container called Microsoft Exchange Security Groups. While creating an Admin Role, you can assign members to the role (users or groups of users) who will gain permissions of Management Roles which are assigned to this administrative role. Below you will find some screenshots that show the way the Admin Role is created in EAC, as well as where you can add new members and how this process is reflected in AD.

 

 

Management Role Assignment

Management Role Assignment maps a user or a group of users’ (known as Admin Role) permissions defined for a single Management Role. Assignment operates on a scope of objects assigned to the Management Role.

How to manage RBAC?

When you manage permissions delegation in Exchange 2013/2016 using RBAC, you need to perform a lot of actions. First of all, you need to create a new Admin Role and assign to it specific, built-in Management Roles and group of users. The easiest way to achieve that is by using EAC. In the screenshot below, you can see a step-by-step example of creating a new Admin Role called 2nd Level Support Management with a Management Role called Mail Recipients assigned to it. One of the members of Admin Role 2nd Level Support Management will be a security group named 2nd Level Support which will consist of User1 member. Below you can see the process:

 

 

The same result you can achieve by executing the cmdlet presented in the screenshot below:

If you want to display all Admin Roles installed on Exchange 2013, you need to access EAC and go to Permissions -> Admin Roles or execute this cmdlet in EMS:

Get-RoleGroup

In order to display all Management Roles use:

Get-ManagementRole

The result is shown below:

In some cases, you may need to view Management Roles that contain a specific cmdlet or cmdlet’s parameters. Two screenshots below show how you can display all Management Roles containing cmdlet New-DistributionGroup or a cmdlet’s parameter Phone.

However, if you want to check all cmdlets assigned to all Management Roles, you can use this cmdlet:

Get-ManagementRoleEntry ‘*\*’

The part of this cmdlet presented as ‘*\*’ should actually look like <name_Management Role>\<cmdlet’s name>. It means that you can adjust the cmdlet to your needs by providing a name of the Management Role and the full name of a cmdlet (or the name partially replaced with “*”). For example, if you want to display all cmdlets with the “Get-“ prefix that are part of the Management Role named “Database” you need to execute:

Get-ManagementRoleEntry ‘Databases\Get-*’

As mentioned previously, Management Role Assignment is a kind of mapping of a single Management Role to a specific Admin Role. Each Management Role Assignment has its own name that is set according to this pattern: <name_Management Role>-<name_Admin Role>. In order to display all Management Role Assignments you need to just type this cmdlet in EMS:

Get-ManagementRoleAssignment

This command can be modified by using a name (or a part of the name) of a specific Management Role along with the asterisk sign “*” which allows for displaying the list of management role assignments to Admin Roles. For example, by executing the cmdlet:

Get-ManagementRoleAssignment 'Audit Logs*'

It will result in displaying a list of assignments of the Management Role named Audit Logs assigned to specific Admin Roles. See below:

Executing the cmdlet Get-ManagementRoleAssignment with a parameter –RoleAssignee and its value as the name of a certain user will show all assignments of Management Roles assigned to Admin Roles which contain the user in question (even if that user is a member of a group which is a member of Admin Role). Below you can find the result of executing the cmdlet:

Get-ManagementRoleAssignment –RoleAssignee User1

(User 1 is a member of 2nd Level Support group, which is further the member of Admin Role called 2nd Level Support Management to which Management Role named Mail Recipients is assigned).

Examples of use

Role Based Access Control can be tremendously useful. In this section, you will see how RBAC can be used for delegating permissions that allow for security group membership management for members of 2nd Level Support Group. User1 and User2 are members of this group.

All Distribution groups are located in OU named Distribution Groups.

In order to allow members of 2nd Level Support Group for membership management in distribution groups, it is necessary to grand them permissions to execute the following cmdlets:

Get-DistributionGroup

Get-DistributionGroupMember

Add-DistributionGroupMember

Remove-DistributionGroupMember

In the first place, it is necessary to determine which of built-in Management Roles consist of the cmdlets mentioned above. This can be checked by using:

Get-ManagementRole –cmdlet <name_cmdlet>

The screenshot below shows the result of this cmdlet:

From the Management Role list containing cmdlets of our interest, we choose the Management Role called Distribution Groups. In order to display all cmdlets included within this role you need to use:

Get-ManagementRoleEntry ‘Distribution Groups\*’

In the screenshot below, you can see the result of this cmdlet:

For the sake of an example, we will create our own Management Role named ModifyDistributionGroupMembership, based on the Management Role called DistributionGroups. The cmdlet is shown in the following screenshot:

Now you need to log in to EAC and create a new Admin Role called 2nd Level Permissions Role, then newly created Management Role called ModifyDistributionGroupMembership and a group named 2nd Level Support Group will be assigned to this Admin Role. In the screenshots below you will find the step-by-step guide how to achieve that:

In the following picture, you can see the result of granting selected permissions. You can notice that User1 is able to modify content of distribution groups.

As you can also see, User1 is granted many more rights than he or she should be.

In order to limit permissions of your new Management Role called 2nd Level Permissions Role, it is necessary to execute the following cmdlet:

Get-ManagementRoleEntry 'Modify*\*' | Where-Object {($_.Name -ne 'Remove-DistributionGroupMember') -and ($_.Name -ne 'Get-DistributionGroupMember') -and ($_.Name -ne 'Add-DistributionGroupMember') -and ($_.Name –ne 'Get-DistributionGroup')} | Remove-ManagementRoleEntry

The following screenshot shows the result of the cmdlet above as well as it displays again the list of cmdlets for the Management Role called ModifyDistributionGroupMembership.

When User1 logs in to EAC one more time, permissions are missing.

To solve this problem, you need to add missing cmdlets:

Get-Recipient

Get-Group

and

Update-DistributionGroupMember

to the ModifyDistributionGroupMembership Management Role.

When you check the User1 permissions again, you can see that they are correct.

Summary

To sum up, Role Based Access Control gives you the possibility of the precise permission delegation – permissions that allow for executing certain actions based on the predefined roles. When ACL (Access Control List) was in use, the whole process of delegating permissions was problematic because it was not clear enough what permissions are necessary to perform certain administrative actions. It was also more demanding for the Administrator who needed to gain comprehensive knowledge about all services he or she managed. Unlike ACL, RBAC lets you quickly check which permissions are assigned to a certain user.