Microsoft Exchange Server 2013 : Role-based access control - Role groups

3/5/2014 3:26:34 AM

Roles can be assigned on an individual basis or on a group basis. Although roles provide the granularity necessary to break down all the tasks a typical Exchange administrator performs, it would be far too complex to assign tasks through individual roles. Role groups provide a convenient method to gather the roles necessary to perform higher-level tasks such as Mailbox Search and avoid the need to assign the 11 roles that would otherwise be required. It’s much easier to manage the assignment of a single role group than it is to manage individual role assignments, and it’s less likely that administrators will make mistakes and create security problems when they manage RBAC through role groups.

Users are assigned roles by making them members of role groups. In effect, a role group describes a high-level set of tasks that you expect a certain type of administrator to perform. For example, technicians working on a help desk need to be able to view and update details of recipients, but you probably don’t want them to mess with a send connector or transport rule. The role group defined for the help desk contains all the roles (and therefore access to all the cmdlets) that are necessary to do the work required by this role and no more.

Role groups provide much of the foundation of the RBAC implementation in Exchange. You can see the built-in role groups (and any that you have subsequently created) with:

Get-RoleGroup

Behind the scenes, every role group is represented by a universal security group (USG) held in the Microsoft Exchange Security Groups OU in Active Directory (Figure 1). The USGs are flagged to Exchange so that it knows that RBAC uses these groups. When necessary, the existing Exchange 2007 ACLs are copied to a role group when the first Exchange 2010 or Exchange 2013 server is installed in an organization that contains Exchange 2007 servers to enable the role group to perform its management function.

Screen shot of the Active Directory Users And Computers console to view the universal security groups created by Exchange in the Microsoft Exchange Security Groups organizational unit. A separate group is defined for each role group. Among the default set Exchange created, the screen shot shows one created by the deployment for a purpose-built role group.

Figure 1. The set of USGs RBAC uses

A key difference between the USGs that instantiate role groups and other USGs is that you can manage role groups (and, by default, their underlying USGs) from EAC and EMS. The Super Help Desk Users (EMEA) USG shown in Figure 1 is not one of the standard USGs created during the installation of Exchange for RBAC. You won’t see it in your Exchange deployment because it’s a USG Exchange created when I created a new role group for my organization. This underlines the point that there is a one-to-one mapping between role groups and USGs.

Inside Out Delegating roles that are not assigned by default

Apart from having access to the vast majority of roles defined in an organization, users in the Organization Management role group can delegate the roles they don’t possess by default. The Mailbox Import Export role is the best example of a role that is not held by users who are part of the Organization Management role group but which a member of that role group can delegate to himself if required. The reason Mailbox Import Export is not held by members of the Organization Management role group is simple: user mailbox contents should be protected against unnecessary access, so you have to take a deliberate step to grant access to mailboxes before you are allowed to run the cmdlets to export or import mailbox data.

Despite the fact that USGs underpin roles, it is a mistake to assume that you could just use the Active Directory Users and Computers console to add user accounts to the USGs to assign roles. Behind the scenes, Exchange notes the role assignments, and adding a user to a USG is not sufficient; it will cause unpredictable results in the future. The Organization Management and Delegated Setup roles are also unique in that they are assigned Active Directory ACLs in addition to Exchange permissions because of the need to have these ACLs to perform tasks that affect non-Exchange parts of Active Directory such as installing servers. The vast majority of the work done by users holding roles to manage the various aspects of Exchange is facilitated by RBAC, so they don’t need to be assigned ACLs.

Role groups and assignments can change over time as Microsoft tweaks RBAC through updates to Exchange. Each role group spans a number of administrative roles that provide granularity for task assignment. The names of the role groups are reasonably descriptive of the tasks you could expect someone assigned to the role group to undertake. The Microsoft goal is to provide a set of role groups that meet the needs of the majority of customers, but you can customize a role group (for example, to remove or add a task) or create a new role group if the default set doesn’t meet your requirements. Again using the default Help Desk role as an example, you might decide that you want these users to see message queues and perform message tracking. In this case, you could customize the Help Desk role group to add the Transport Queues and Message Tracking roles.

It is also possible to assign a specific role to a user or group without placing that user or group in a role group. However, as mentioned earlier, Microsoft doesn’t recommend taking this approach because you are likely to accumulate a proliferation of role assignments that become difficult to monitor and manage.