RBAC and the Triangle of Power
Published Nov 16 2009 05:58 PM 41.4K Views

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 | fl *scope*

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.

  1. You can create a custom role that is the child of an existing custom role.
  2. A child role CANNOT have more rights than its parent role; even if the parent role is a custom role.
  3. 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.

17 Comments
Not applicable
how do you link a AD Universal Security as linked to a Role Assignment? When you create the role group via New-RoleGroup cmdlet, does it create a Universal security group? then use group nesting for assigning the exchange rights? Or do you have to tag the pre-existing or newly created AD Univ. sec. group in some way using another cmdlet?

maybe i read this incorrectly, but that was the only fuzzy part for me :)
Not applicable
Chad,

When you create a new role group it will create a Universal Security Group for you that has the bit flipped to mark it as a Role Group.

You can assign Roles via Role Assignments to any USG or individual user that is in your organization.  It does not have to be a Role Group, role groups exist solely to make administration simpler.

Generally speaking I would recommend that you place the people that you want to have rights directly into the Role Group or USG.  But it will support nesting groups as well.

-Matt
Not applicable
Role Based Administration in Exchange 2010 requires you must have the Courage to do What is needed, the Power to be Where you should be, and the Wisdom of Who has the power. Together Courage, Power, and Wisdom make the triforce of Exchange 2010 power. Thank you, I definately remember RBAC now!!!
Not applicable
Great article, Matt! Here's to hoping SP1 or later will give us the option to apply scopes to the role groups themselves and not the role assignments. :) This would be a huge gain for hosted/co-located type deployments or else I fear RBAC will start looking like today's ACL spray with tons of scopes and assignments to manage.
Not applicable
Great article!.. very useful and innovative blog on 'RBAC and the Triangle of Power'...  Together Courage, Power, and Wisdom make the triforce of Exchange 2010 power. Thank you, I definately remember RBAC now!!!
Not applicable
Agreed with bday.  Role Assignments add too many things to manage.  We should just have Role Groups which contain Roles.  And scopes should be added to Role Groups.  This would make things more manageable.  IMO, RBAC in its current state is just too complicated.
Not applicable
Hi Matt, your recommendation to put users directly into the security group goes against everything Windows has taught us for many years. Windows security model uses the ACL model where each object stores security information about access to itself. Unix/Linux has a model where each object gets given a group and users are members of groups to gain access to objects.
Does this indicate that ACLs will be phased out in the future? Generally well designed AD structures contain role based groups anyway, but these groups are based on the users job rather than access rights - in huge companies this may map to the Exchange roles directly, but generally we create a "user admin" group and all user admin employees should go in this group. Would it be feasible to create the "user admin" group as an Exchange RBAC and then use this for delegation in the rest of the domain? If this is the case then this looks perfect, but you did mention flipping bits to change the group type. Does this reflect in AD as a separate group type?
Sorry not had a chance to test any of this yet - your article will help greatly with that so thanks very much.
Cheers
Dave
Not applicable
I was really confused about RBAC. You made it really esay to undertsand the concept. Thanks You
Not applicable
Hi David,

In response to your question about assigning users directly to a group.  I guess I should have been more specific.  In general you will be assigning RBAC roles to the lowest level in your group structure as possible.  This is because RBAC roles are addative ... so you want to make sure to get i the assignments as close to the user as you can to ensure that no one gets rights they are not supposed to get.

In the case of Role Groups ... Please do not think that you need to go and create a whole new group structure to manage RBAC on top of your existing Groups.  Role groups are just an exchange "construct" to make RBAC managment a touch easier.  You can assign an RBAC role to any Security Group, or User object in AD.  So you can assign any roles you create directly to your existing AD group structure.

If you want an existing Security Group to show up as a Role Group you can change a few properties in AD and will show up.

msExchCoManagedByLink: CN=Organization Management,OU=Microsoft Exchange Security Groups,DC=domain,DC=com;
msExchRecipientTypeDetails: 1073741824;
msExchVersion: 44220983382016;

Hopefully that clears up your concerns?

-Matt
Not applicable
Joe and Bday,

I understand you fear ... and I share it to a degree that you are going to end up with this spray of role assignments.  But I am afraid we are going to have to keep them.

The Assignments are nessicary since they allow you to link the role to the scope to the group ... it is the piece that puts everything together.

Now maybe we could have done this with just being directly on the group and not being a seperate object ... but the advantage of the assingment is the you can mix and match all three of these things for maximum flexability.

You could have a single group that had only the ability to change a few attributes for users in OU=Executives ... but then had the ability to change more attributes in OU=Users.  This is only possible when we have the granularity that Role Assignments offer.

-Matt
Not applicable
Hey, Matt. With all due respect I see the vision, but it just doesn't work for larger orgs with highly decentralized administration. While RBAC is no doubt leaps and bounds better than what we had before, for some it will only move the permissioning spray from one area to another and become unmanageable. I think the Exchange team needs to take another look at things and perhaps steal a chapter from AD OU design, and by that I mean understand one way works for some deployments and another way works for others. I had high hopes for RBAC (still do), but without being able to scope directly to groups or being able to use databases as a scoping object, it doesn't get us much. <whimpers>
Not applicable
Hi bday,

I understand your concern.  And to a degree in a large organization you are still going to end up with some spray.  There is just no way around that if you are a highly decentralized administration model.

The advantage of RBAC in that situtation is that all of your managment is in one place.  There is no hunting thru ADSIedit for the complex AD permissions that you need to set to limit this users to a set of actions.  It is all done with RBAC.  So yes you end up with 100s of Assignments ... but all of your management is in one place, using one set of rules, and one common easy to understand rule set.

Also with RBAC you can reuse quite a bit, from roles assigned with different scopes to different roles with the same scopes.  The number of Roles and Scopes you have to created is limited ... you just need to setup all of the assignments matching the Scopes with the Roles.

In reference to your Scope request ... currently can you setup scopes using group membership.  e.g. a scope can be defined as all members of Group "VIPs".  Database scoping is not currently in the product but was a big ask of the tap members on the beta so I suspect we are working on that for the future.

-Matt
Not applicable
This all looks really great but when I ran the exercise the member of the new Role Group did not appear to have the two PS commands as I expected.  What is the best test to see the effects of all these efforts.

thanks

Dick

btw it is a great explanation.  Could you do another one for the Role Policy assignement?  :)
Not applicable
Dick,

Well ... it looks like I was defeated by my own haste and an assumption or two.

The easiest way to test that this is working is to log in as the a user in the "VIP Editors" Group and make sure you can change one of the parameters that we defined.  The problem there is that if you do this it will fail.

The reason is that I didn't include enough parameters on the set-user command for it to actually work.

The command you actually need to run is:

Add-ManagementRoleEntry "VIP EditorSet-User" -Parameters Office,Phone,Mobilephone,Department,Manager,Identity,whatif,erroraction,errorvariable,verbose,debug

Now ... the only one of those that I think you HAVE to have to get this to work is identity ... but the rest are good to have as well.

-Matt

PS. I will submit a correct to this article and get it updated as quickly as possible.
Not applicable
Thansk Matt, as soon as I looked at that I realised what was missing.  An explanation of these would be useful or rather how the parameters are interpreted.

This was an excellent article BTW as I had basically plodded my way through before, worked it out but not really formulated a mental image of the whole thing.

As I said before, an explanation of the EndUser Policy would be a great help too...

cheers,

Dick
Not applicable
Call me silly but why can this whole RBAC not be managed from the Exchange Management Console?
Not applicable
Hi Geert,

Some RBAC managment can currently be done the ECP (via OWA).  

I believe that improving the RBAC administrator experience is a goal for SP1.

-Matt
Version history
Last update:
‎Nov 16 2009 05:58 PM
Updated by: