Permissions and Role Based Access Control (RBAC) – Part I

Posted on April 29, 2011 by J. Peter Bruzzese in Exchange Server with 0 Comments

Pre-Exchange 2010 vs. Exchange 2010 Permission Models

Microsoft Exchange Server 2010 now comes with the new RBAC (Role Based Access Control) permissions model. This new permissions model allows you to define both a broad, as well as a more granular assignment of permissions to administrators. The roles you assign to administrators can reflect more accurately the actual roles they perform in your organization.


Previous to Exchange Server 2010, Microsoft Exchange administrators who needed to create new administrators, or assign new permissions to existing ones, used to get stumped when deciding which administration group to assign administrators to. Each administration group contains different sets of permissions, and older versions of Exchange had only a few administration groups to choose from. As a result, administrators often ended up being assigned to admin groups that enabled them with more permissions than were appropriate for their role.

Note: If you’re familiar with the concept of role groups and roles, you can go straight to the section “Predefined Role Groups and Roles”.

(Instructional video below provides a walkthrough of the steps contained in this article.)

Role Groups and Roles

An important concept you need to understand in order to appreciate RBAC is the relationship between role groups, roles, cmdlets (commandlets) and parameters.

First of all, a role defines a set of tasks a particular administrator can perform. For instance, the ‘Mail Recipients’ role enables admins to perform the tasks of managing mailboxes, mail users, and mail contacts. When an admin is assigned a role, he is, in effect, granted the permissions that come with that role. The act of ‘granting permissions to perform certain tasks’ simply translates to giving access to the cmdlets or parameters associated with those tasks.

In some cases, a single admin will need to be assigned multiple roles. It is possible to collect a set of roles, put them together in what is known as a role group, and then assign that role group to an admin.

Conversely, it is also possible to assign multiple members (admins) to a role group. This means, all those admins assigned to that role group will be able to perform similar roles and, as a consequence, will have access to the same cmdlets and parameters included in those roles.

Predefined Role Groups and Roles

It is worth noting that while you can perform granular assignments in Exchange 2010, there are also Predefined Role Groups that you can use if you’re still learning your way around RBAC and temporarily want an easier way of assigning permissions.

If we include all predefined role groups (specifically called Predefined Universal Security Groups), there are 16 in all. However, only 11 are really used for RBAC. The rest are used internally by Exchange. In this article, we’re more concerned with the role groups used for RBAC and have listed them below, along with a brief description for each one.

Predefined Role Groups used in Exchange Server 2010 Role Based Access Control:

  1. Delegated Setup – For admins who need to deploy Exchange 2010 servers that have been previously provisioned by a member of the Organization Management role group.
  2. Discovery Management – For admins who need to perform searches of mailboxes for data that meet specific criteria as well as configure legal holds on mailboxes.
  3. Help Desk – For admins who need to view and modify the Microsoft Office Outlook Web App options.
  4. Hygiene Management – For administrators who need to configure the virus and antivirus features of Exchange.
  5. Organization Management – For admins who need to have administrative access to the entire Exchange 2010 organization.
  6. Public Folder Management – For administrators who need to manage public folders and databases on servers running Exchange 2010.
  7. Recipient Management – For admins who need to manage Exchange 2010 recipients.
  8. Records Management – For administrators who need to configure compliance features such as retention policies, message classifications, and transport rules.
  9. Server Management – For admins who need to set server-specific configurations of transport, Unified Messaging (UM), client access, and mailbox features.
  10. UM Management – For admins who need to manage UM-related server configurations, properties on mailboxes, prompts, and auto attendant configurations.
  11. View-Only Organization Management – For administrators who need to view the properties of any object in Exchange.

I’ll now proceed to show you how to delegate these predefined roles to your administrators.

Delegating Predefined Roles

First, open up your Exchange Management Console. In the leftmost panel, select Toolbox. Next, go to the center panel, scroll down, and click Role Based Access Control (RBAC) as shown below.

Exchange 2010 RBAC: bRole Based Access Control

That action will take you to the Exchange Control Panel, where you will be asked to login. After doing so, navigate to the Administrator Roles panel.

Exchange Server 2010 Control Panel

Under Role Groups, you’ll find a list containing all eleven Predefined Role Groups mentioned earlier. Each time you select a role, its corresponding Description, the roles assigned to it (known as Assigned Roles), and the administrators given those roles (known as Members) will be shown in the panel on the right (see screenshot above).



To assign a Member to a Predefined Role Group, just double-click on a Predefined Role Group on the list. This should take you to that particular Role Group’s own window. For example, double-clicking Discovery Management brings up the window you see below.

Exchange 2010 RBAC: Role Groups

There you’ll see the role group’s name (in our example, it’s “Discovery Management”), a brief description of the role group, Assigned Roles and write scopes, as well as a list of members at the bottom (initially empty). To add a member, just click on the “+ Add” button as shown in the screenshot above.

In the next window, find and select the name of the admin you want to add as a member, then click OK.

Exchange Server 2010 RBAC: Role Groups

You’ll then see the newly added member in the previously empty Members box.

RBAC Role Groups

If you have more admins to add to this role group, you may continue doing so here. When you’re done, click the Save button.

Remember that, not only are you allowed to add multiple admins as members of a role group, you can also assign multiple role groups to a single admin. Again, you do that in the Administrator Roles panel.

Exchange Server 2010 Role Based Access Control

The RBAC Triangle of Power

Before we end this article, let’s have a look at a graphical representation that summarizes how RBAC works.

Members of the Exchange team like to depict the workings of the RBAC with what they call the “Triangle of Power”.

RBAC Triangle of Power

The Triangle of Power is made up of four main components: the Where, the What, the Who, and the Glue.

The Where or Scope represents the range over which a particular role assignment is supposed to apply, i.e., a single organizational unit, a single user, a group of users, or the entire organization.

The What or Role represents what your role can actually do. Exchange Server 2010 has 65 built-in roles that you can either use straightaway or build from.

The Who or Role Group, as we mentioned way back, is simply a collection of roles (which in turn are made up of cmdlets and parameters). You combine this with the Scope to come up with a complete Role Assignment.

Beyond RBAC’s Predefined Roles

As you’ve seen earlier, using the RBAC’s predefined role groups can significantly simplify your job of granting permissions to other administrators. However, what we took up was just the broad way of assigning permissions using RBAC.

What if you want someone to make transport rules but don’t want him to have anything to do with retention rules and message classifications? Obviously, assigning him to the Records Management role group would not suffice because it would grant him more permissions than you want him to have.

For this task, we would need to take on the granular way of assigning permissions in RBAC, which is found in Part II of this article.