Sergiy Serdyuk - Fotolia

Get started Bring yourself up to speed with our introductory content.

How Exchange RBAC helps you set permissible tasks

Once you know how to use it, RBAC can help you define which commands and tasks end users can access and perform in Exchange.

Role Based Access Control is a feature in Exchange 2013 that gives admins the power to determine which cmdlets and parameters are available to their end users. The administration tool uses an authorization model containing three pillars: the types of tasks end users are allowed to perform, permissions for who can perform those tasks and where within the organization the tasks can be executed.

To get admins acquainted with Role Based Access Control (RBAC), let's dig deeper into the first pillar: defining which commands someone is allowed to use and which tasks someone can perform in an Exchange ecosystem when looking at these commands in a bigger context.

In Exchange RBAC, the ability to execute cmdlets in combination with certain parameters determines an administrator's capabilities. The Exchange Administrative Center (EAC) is built on top of that model, and being dynamic, allows for access to only the functionality that RBAC grants. Each combination of allowed cmdlets and parameters is defined in a Management Role Entry. A set of Management Role Entries can be attached to a Management Role, and in turn, these Management Roles can be assigned to end users or groups.

For example, let's look at the built-in Management Role 'UM Prompts' used to delegate management of unified messaging voice prompts. If you want to view all defined Management Roles, use the Get-ManagementRole command. To view the long list of all defined Management Role Entries, use Get-ManagementRoleEntry –Identity '*\*'.

To see the definition of the Management Role 'UM Prompts' in terms of cmdlets and parameters, you can use this command to find that information (Figure 1):

Get-ManagementRole -Identity 'UM Prompts' | Get-ManagementRoleEntry | Select Name, Parameters | fl

UM Prompts cmdlet
Figure 1. This is an example of a result you may see if you use a certain cmdlet to see the definition of the Management Role 'UM Prompts.'

This Management Role contains 10 cmdlets, each with its own set of parameters. These parameters can be a subset of what would normally be available. Note that for each Set-* cmdlet, the related Get-* cmdlet should also be included; this is because most cmdlets and the EAC need to be able to read the properties before they allow you to set those properties.

We can also create our own Management Role with its own set of Management Role Entries. For this example, we'll create a Management Role to allow the setting of user photos via the UserPhoto parameter. We can't create a role from scratch in Exchange RBAC. We need to base it to a so-called parent role, after which we strip all unnecessary cmdlets and parameters and add new ones. Because this is similar to 'Mail Recipients,' which is used for managing mail recipients, we'll pick that one:

New-ManagementRole -Name 'User Photo' -Description 'This role enables administrators to manage user photos' -Parent 'Mail Recipients'

We've now created a new role that contains the same Management Role Entries as its parent. To see if the *-UserPhoto cmdlets are already part of the Management Role Entries, we can use:

Get-ManagementRole -Identity 'User Photo' | Get-ManagementRoleEntry | Where { $_.Name -like '*-UserPhoto'}

We'll assume that they are part of the entries in our example, so we need to remove all other cmdlets from this Management Role. However, next to the *-UserPhoto cmdlets, we also need to keep the Set-ADServerSettings and the Get-ADServerSettings cmdlets because these are used during the initialization of EAC. We can accomplish all of this by piping all Management Role Entries of 'User Photo', and removing the ones we are not interested in by using Remove-ManagementRoleEntry:

Get-ManagementRole -Identity 'User Photo' | Get-ManagementRoleEntry | Where { $_.Name -notlike '*-UserPhoto' -and $_.Name -notlike '*-ADServerSettings'} | Remove-ManagementRoleEntry

Finally, verify that the proper cmdlets have been retained (Figure 2):

Get-ManagementRole -Identity 'User Photo' | Get-ManagementRoleEntry

Management Role Entry cmdlet
Figure 2. This is an example of how you'll verify that the right commands are properly retained.

The definition of this role is now finished. However, what if the presence of a photo is related to the information in the mailboxes' extensionAttribute15? We can't read or modify that value using this role, so we need to add related cmdlets and parameters.

First, let's add the Get-Mailbox and Set-Mailbox users:

Add-ManagementRoleEntry –Identity 'User Photo\Get-Mailbox -Parameters Identity, extensionAttribute15

Add-ManagementRoleEntry –Identity 'User Photo\Set-Mailbox' -Parameters Identity

Because we didn't include extensionAttribute15 in the Set-Mailbox entry, we can use the Set-ManagementRoleEntry cmdlet to fix this omission:

Set-ManagementRoleEntry –Identity 'User Photo\Set-Mailbox' –Parameters extensionAttribute15 –AddParameter

Similarly, to remove a specific parameter, we can specify it and use the RemoveParameter cmdlet. For example, to disallow using the Preview parameter with Set-UserPhoto cmdlet, we can use:

Set-ManagementRoleEntry -Identity 'User Photo\Set-UserPhoto' -Parameter Preview -RemoveParameter

To quickly get a list of all Management Roles that allow admins to use the Set-UserPhoto in some way, you can use:

Get-ManagementRole –Cmdlet Set-UserPhoto

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 theucarchitects.com and blogs about Exchange and related subjects at eightwone.com.

Next Steps

This is part two in a series on Role Based Access Control in Exchange 2013.
Part one introduced RBAC and took a brief look at how the feature works.
Stay tuned for part three, which will discuss the next pillar of Role Based Access Control: how to assign who'll have permissions through RBAC.

Dig Deeper on Exchange Server setup and troubleshooting

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.

-ADS BY GOOGLE

SearchServerVirtualization

SearchCloudComputing

SearchSQLServer

SearchEnterpriseDesktop

SearchVirtualDesktop

Close