If you would like to read the other parts in this article series please go to:
Introduction
In this article series, we are going over some scenarios using RBAC to delegate specific permissions to any given user or group of users. First, we are going to show how it works in the most basic way using EAC (Exchange Admin Center) to create a new Admin Role Group using default values. After that, we will be working on some classic scenarios to overcome some challenges that an administrator may have, such as: allow management just for specific type of objects: contacts, groups and mailboxes.
The Exchange Team made a great job blogging about RBAC. The triangle of power and this article give us all the background that we need to start this series. We are going to start this series using those concepts and applying them in real life scenarios of any exchange administrator.
The goal for this first article of our series is to get used to the naming convention of RBAC when dealing with Exchange Management Shell and Exchange Admin Center in Exchange Server 2013.
Understand the process (Admin Role Groups, Management Roles, and Management Roles Assignments)
Using EAC (Exchange Admin Center), an administrator is able to list all Admin Role groups by clicking permissions item located on the left and on the right side a list of all existent Admin Role Groups will be displayed. We can get the same information running Get-RoleGroup using Exchange Management Shell (Figure 01).
Figure 01
An Admin Role Group will combine several components: one or more Management Roles, a scope, users and all that will set the boundaries for the member to manage and perform tasks in our Exchange server environment.
In order to create new Admin Role Groups, we can always click on Add or copy an existent one using Exchange Admin Center and from there start doing our customization. In Figure 02, we created a new one from scratch and labelled it as MSExchangeORG. The first page on the left side is the Admin Role Group, and when we click the Add button on a Role we will see a list of all Management Roles (we can use Get-ManagementRole using Exchange Management Shell).
In order to continue our analysis of the process, we will add only Mail Recipients and a test user account into that brand new Admin Role Group that we are creating (in our case the user will be user77). Click save and the new group should be listed on the main page of Admin Role Groups.
Figure 02
The result of creating a new Admin Role Group can be seen on the Active Directory Users and Computers where a new Universal group will be created. The user that we specified will be added to that group, as shown in Figure 03.
Figure 03
Do you remember that “Glue” component explained in the Triangle of Power article? That was created automatically and we can see the results running Get-ManagementRoleAssignment cmdlet and the result will be one or more entries (depending on the number of Management Roles assigned in the Admin Role Group) using the following standard <Management Role Name>-<Admin Role Group>, as shown in Figure 04.
Figure 04
To make it clear, for any new Management Role added to an Admin Role Group, the result will be a new Management Role Assignment. For example, if we go back to the same MSExchange Admin Role Group that we have just created and add the Role Distribution Groups we will have the following results using the same cmdlet that we have just ran in the previous figure (Figure 05).
Figure 05
Okay, so far we went through the process of creating a new Admin Role Group using Exchange Admin Center (EAC) and we verified what is going on under the hood when we do trivial things, adding a Role to the Admin Role Group etc.
If we can understand where each component fits when using the web interface would be a great start. It will help us a lot understanding the upcoming articles where we will work on removing unnecessary features in our customized delegation process for our future administrators.
Before getting there, we need to understand one more thing. So far we have no idea based on the tasks that we performed what a user can or cannot do, right?
Let’s start that all cmdlets can be found under the Management Roles (or Roles section when using Admin Role Group in Exchange Admin Center). The first Role that we added was Mail Recipients, in order to understand the cmdlets that form such Management Role we can run the following syntax:
Get-ManagementRoleEntry <Management Role>\<cmdlet>
Since we know that the Management Role that we added is “Mail Recipients” we can type in “Mail Recipients\*”. We are going to use \* because we have no idea of which cmdlets we have on that specific management role (Figure 06).
Figure 06
If we want to be more specific, we can always run Get-ManagementRoleEntry <ManagementRole>\<cmdlet> | fl (Figure 07) and a list of parameters and additional information will be listed.
Figure 07
RBAC Survival cmdlet kit…
At first the cmdlets that we went over can be a little bit confusing but trust me after doing a couple of tests, failing half, getting the other half kind of okay we will get used to it. After that it is going to be easier than a walk in the park. The following hints will help you speed up the learning process.
Hint #01: Using wildcards to get the cmdlets with Get-ManagementRoleEntry
In the previous image, we specified the entire Management Role name (Mail Recipients) to get some information but that is painful and we can use wildcards to get the same results. Also, when using Get-ManagementRoleEntry we need to think that the first parameters (Management Role) is like a folder and the cmdlets are the files, so we always need to specify <ManagementRole>\<Cmdlet>.
For example, we can use “Mail*\*” but we must pay attention on the second column for more generic names because that column will identify which Role (Management Role) we are getting information from. In Figure 08 we are getting cmdlets of any Management Role that starts with Mail, that is why the output is extensive (we have several built-in Management roles starting with Mail).
Figure 08
Hint #02: How to find a cmdlet in a Management Role
In some cases, we want to start creating our customization to delegate permissions and we know the cmdlet but we may not have any idea which Management Role(s) use it. In order to find out which Management Roles use a cmdlet, we need to use the following syntax:
Get-ManagementRole –Cmdlet <CmdLet>
In Figure 09, we are able to find out the Management Roles for both New-MailContact and Disable-Mailbox cmdlets.
Figure 09
Using the same principle we can search for a specific parameter. Let’s say we want to find out which Management Role contains cmdlets that use the Database parameter. We can use the same Get-ManagementRole with –CmdletParameters to narrow down our list.
Figure 10
Hint #03: How to find out if a user has any permissions associated to it
Let’s use the user77 that we used previously, in order to identify where the user has permissions we can run the following syntax: Get-ManagementroleAssignment –RoleAssignee <username> and the result will be a list with all assignments. On the third column RoleAssigneeName we will have the Admin Role Group name.
Figure 11
This cmdlet is extremely helpful when troubleshooting permissions to existent users, sometimes you have a user that has too many permissions and the reason is that he is showing up on more than one Admin Role Groups. Using this cmdlet we can spot in a single glance where is the issue.
Hint #04: Always logoff
When working with RBAC permissions, make sure that you logoff and log back on to your session after managing any permissions.
Conclusion
In this first article of this series we went over the process of creating a simple Admin Role Group and we analyzed what happens in the environment during the process. In our next article we are going to start the customization for Mail Contacts.
If you would like to read the other parts in this article series please go to:
