Permissions and Role Based Access Control (RBAC) - Part I
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.
Say Goodbye to Traditional PC Lifecycle Management
Traditional IT tools, including Microsoft SCCM, Ghost Solution Suite, and KACE, often require considerable custom configurations by T3 technicians (an expensive and often elusive IT resource) to enable management of a hybrid onsite + remote workforce. In many cases, even with the best resources, organizations are finding that these on-premise tools simply cannot support remote endpoints consistently and reliably due to infrastructure limitations.
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:
- 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.
- 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.
- Help Desk – For admins who need to view and modify the Microsoft Office Outlook Web App options.
- Hygiene Management – For administrators who need to configure the virus and antivirus features of Exchange.
- Organization Management – For admins who need to have administrative access to the entire Exchange 2010 organization.
- Public Folder Management – For administrators who need to manage public folders and databases on servers running Exchange 2010.
- Recipient Management – For admins who need to manage Exchange 2010 recipients.
- Records Management – For administrators who need to configure compliance features such as retention policies, message classifications, and transport rules.
- Server Management – For admins who need to set server-specific configurations of transport, Unified Messaging (UM), client access, and mailbox features.
- UM Management – For admins who need to manage UM-related server configurations, properties on mailboxes, prompts, and auto attendant configurations.
- 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.
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.
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.
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.
You’ll then see the newly added member in the previously empty Members box.
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.
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”.
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.