Introduction
Role Based Access Control (RBAC) is the new permissions model in Microsoft Exchange Server 2010. With RBAC, you don't need to modify and manage access control lists (ACLs), which was done in Exchange Server 2007 and earlier. On the flip side - as with anything new, RBAC can seem a bit intimidating at first.
I am going to try an explain how to think about RBAC, and the order to create things in so that you end up with a working RBAC setup that does exactly what you want. As we go thru each piece we will be setting up a custom role so feel free to follow along with the commands in your environment.
The Triangle of Power
We jokingly call this image the RBAC triangle of Power. It is the key to understanding RBAC and exactly where each piece of the puzzle fits. Once you understand the triangle understanding what is going on with RBAC is quite easy.
I will explain each of the nodes of the Triangle then put them back together for us at the end.
The Where
The first thing that you should work with when setting up RBAC is the where. By where we mean, where can the assignment you are about to build operate? Can it operate on one OU, a group of users, or maybe in the configuration container?
By default all RBAC roles have a defined where. That is the default scope that is assigned to the Role. You can see the default scope of a role by running
| Get-ManagementRole |
This will show you the implicit scopes of the role. The ones to pay attention to are the implicit write scopes. These will define where the cmdlets in the role can write.
When you create a new RBAC role it has to be a child of an existing RBAC role. If you do not define a scope for your newly created role it will inherit the scope of the Parent role. If you didn't want to use the default scope; say you wanted a role that could only work against VIPs you would need to create a new scope.
You can define the scope directly when you assign the role; but if you think there is any chance that you will need this same scope again for another role I would recommend that you create a new scope object. To do so you would use the New-ManagementScope cmdlet to do something like this:
| New-ManagementScope -name "VIP Users" -RecipientRestrictionFilter {memberofgroup -eq "cn=VIPs,ou=VIP,dc=domain,dc=com"} |
This will create a scope named "VIP Users" that will apply only to people that are in the group VIPs. Once you have your scope object created you need to define the What part of the triangle.
The What
Now that you know where your role is going to be able to act it is time to create, what your role is going to be able to do.
By default Exchange 2010 has 65 built in roles. Each of these roles was created to cover a given set of discreet tasks that the product group thought would be useful to how our customer's environments work. But they are not going to cover all scenarios.
So we gave you the customer the ability to create child roles off of the built in parent roles and to use these to customize how your users and administrators can interact with Exchange.
There are some key things to know about user created roles.
- You can create a custom role that is the child of an existing custom role.
- A child role CANNOT have more rights than its parent role; even if the parent role is a custom role.
- You should always have a get cmdlet for each set / remove / etc. cmdlet that you have in the role.
You control what a role can and can't do by adjusting the cmdlets and cmdlet parameters that are on the role. To see what entries already exist on a role we run:
| Get-ManagementRoleEntry "Mail Recipients\*" |
That will show us all of the cmdlets that the Role "Mail Recipients" is allowed to run. We will create a child role of the "Mail Recipients" role and give it only the ability to modify a few things on another user's mailbox.
First we create the Role:
| New-ManagementRole -Name "VIP Editor" -Parent "Mail Recipients" |
Now since we only want this role to do a few things the easiest thing to do is to remove everything from the role and only put back the one or two things we want.
| Get-ManagementRoleEntry "VIP Editor\*" | Where {$_.name -ne "Get-User"} | Remove-ManagementRoleEntry |
What we did was remove all but one Entry from the role. Powershell won't let you remove all of the entries and for what I am building leaving the get-user cmdlet on was a reasonable one to leave there. It is very important to note that if you want to do the set version of a cmdlet you should have the get version of the same cmdlet on the role. It is hard to modify what you can't see.
Now we add back the one set cmdlet that we want with only the parameters that we need.
| Add-ManagementRoleEntry "VIP Editor\Set-User" -Parameters Office,Phone,Mobilephone,Department,Manager |
This allows our "VIP Editor" role to only edit the attributes listed in the Parameters section of the cmdlet.
At this point we have created the What and now we need the Who.
The Who
The Who is simply; who is going to be able to perform, the What on Were.
For that we have to decide if we are going to assign this role to one specific person or to a group of people. The best practice is to always assume that you are going to assign the role to a group of people.
To provide the Who for a group of people we use a role group. A role group is actually just a normal Universal Security group that we have flagged to indicate it is being used for RBAC role assignments. This is done to make it easier to manage these groups.
We can see the built in exchange role groups by running:
| Get-RoleGroup |
This will show us the default role groups that Exchange ships with that are designed to handle most of the big bucket administrative tasks that a majority of customers use. For our purpose we want to create a new role group to define who can work with our what, where.
| New-RoleGroup "VIP Editors" -Roles "VIP Editor" -CustomRecipientWriteScope "VIP Users" |
When you create a role group you must assign at least one role to the group. You can assign multiple roles if you need the members of the group to perform more than one set of tasks. Optionally you can also assign the scope when you create the role group. If you do not assign a scope it will take the default scope of the role.
Once the role group is created the role, and scope combination will take effect. The reason it takes effect is that the New-RoleGroup cmdlet has automatically created the glue for us.
The Glue
The Where, What, and Who are all AD objects. The Where is a scope object. The What is a role object, and the Who is a special security group. So naturally the Glue is another AD object, the Role Assignment, which sticks these three other objects together to create a working RBAC definition.
Above when we created the Role group the New-RoleGroup cmdlet created the role assignment for us in the background. We can see the role assignments with:
| Get-ManagementRoleAssignment |
You will see that there are around 160 or so of them. This is because each role assignment is a 1 to 1 mapping of a Role, to a Scope, to a Role Group/user/Role Policy. So every time I assign a role to a role group it will create another unique role assignment that glues together the needed objects.
NOTE: This is critically important! RBAC roles are not like security permissions where the most restrictive wins. RBAC instead provides the end user with the UNITY of all roles that have been assigned to them. So only apply the exact roles to a user that you want them to have.
I take a role away from a role group by simply removing the role assignment that glued that role and role group together.
Pulling it all together
I know I have thrown quite a bit at you, and that I skimmed over a few things. But, I am trying to give you the basic structure and to get you thinking about RBAC roles in the right way. You have to think about them in the right order and know where all of the little bits fit before it makes sense. I know for quite a few of us on the Exchange 2010 beta team we heard the explanation then three days later we went... Oh... So that's how it works.
From our experience the key when working with RBAC is to think of the triangle and to do things in the right order so that all of your bits are there and setup when you need them. Here is the finished Triangle of power that will help pull it all together:
Conclusion
RBAC isn't that hard. The key is to follow the triangle and create things in the right order. Create the Scope first, then the Role, then the Role Group. With the understanding that the Role Assignment is created to glue together these three pieces.
The only other thing with RBAC that makes it hard to work with, and communicate about is the fact that there are so many words in RBAC that contain the word role... it is easy to get confused about what is what. So here is a handy Reference of what each key concept means and the cmdlet noun associated with it. Make sure to communicate exactly what you are talking about when discussing this with others.
Scope - The scope defines the objects in AD that the Role can act on. It is considered the Where part of the triangle since it defines Where the role can act. The noun associated with scope is ManagementScope
Role - The Role is the collection of Role Entries that defines a set of cmdlets and parameters that can be run. It is the What part of the triangle since it defines What you can do. The PowerShell noun associated with Role is ManagementRole
Role Entry - The Role entry is the actual entry on the role that defines an individual cmdlet and parameters on the role. This is the granular piece that you edit when you make a custom role to do only what you want. The PowerShell noun associated with Role Entries is ManagementRoleEntry
Role Group - The Role group is a security group that defines Who gets a specific role or scope applied to them. It is the Who part of the triangle since it defines who is able to perform the actions. The PowerShell noun associated with role groups is RoleGroup
Role Assignment - The Role Assignment is the glue that holds together the Who, What, and Where. It is the AD object that pulls together the other three and defines Who can do What, Where. The PowerShell noun associated with the Role Assignment is ManagementRoleAssignment
- Matt Byrd
Special thanks to Jonathan Runyon for some of the information used in this post.