Have you ever heard the expression “It’s not what you know, it’s who you know”? This is often true in the real world, and it’s equally true for computer systems. Most systems rely on the idea that every user has an individual account that is not shared with, or accessible by, other people. That paradigm has been in effect for nearly 50 years, and it still holds up pretty well for most uses. In some cases, however, you don’t want to assign permissions or user rights to individual users. Instead, it might be more effective to assign those permissions to someone who holds a particular role.
For example, consider the case of a small company that has three employees who handle accounts. Any one of these people has the ability to sign checks, pay bills, and perform other accounting functions. It seems reasonable that you might assign permissions in Active Directory (AD) or even in Microsoft Exchange Server directly to these users. But consider a company that has 3,000 people in its accounting department. Making individual permission assignments to this many users—either individually or in groups—might not be the most efficient way to handle the situation.
As with so many other problems in computing technology, the solution to this situation has existed for nearly 40 years. Time-sharing computer OSs such as OpenVMS and Multics originated the idea of giving permissions to a role, not a user. By assigning permissions for certain objects to the accounts payable role, for example, and then giving users that specific role, it becomes simpler to understand, monitor, and audit which users have which permissions. Unfortunately, role-based access control (RBAC) was largely ignored as part of the transition from large-scale mainframe systems to commodity servers that run Windows or Linux. Now, Exchange Server 2010 has brought back RBAC with a vengeance.
Exchange and RBAC
Exchange 2000 Server introduced the concept of Exchange-specific roles. The Exchange Administrator, Exchange Full Administrator, and Exchange View Only Administrator roles could be used to assign capabilities to individual users or groups. These roles were a fine idea, but they were limited because of the way in which they were implemented. There were two primary limitations. First, the roles were not very granular, making it difficult to assign the exactly correct access or to assign many users. Second, the Exchange management tools themselves had to rely on Windows for authentication information. Windows itself doesn’t implement all the underpinnings that are required for RBAC. Accordingly, Exchange couldn’t do much more than impose some access checks to verify whether a user account held one of the administrator roles.
Exchange 2010 changes this completely. As in Exchange Server 2007, every action that a user or administrator can take in Exchange Management Shell (EMS), Exchange Management Console (EMC), or Exchange Control Panel (ECP) actually calls one or more PowerShell cmdlets. Exchange Role Based Access Control (RBAC) lets administrators control which specific PowerShell commands—and even which arguments to commands—an individual user can execute. This is quite a departure from the old model, so it will require some explanation.
RBAC Basics
RBAC depends on three sets of definitions: management role, management role group, and scope. These can be described as follows.
A management role specifies what can be done. For example, Exchange 2010 defines roles for unified messaging (UM) management, discovery management, and other administrative operations. Users who hold one of these roles can take specific actions that are allowed in the definition of that role. In Exchange, the role is made up of role entries, each of which defines an EMS cmdlet or set of parameters that users who hold that role can execute. Exchange 2010 SP1 includes definitions for about 70 roles: for moving mailboxes, working with mail recipients, managing legal holds, and so on. Some of these roles are intended for administrators, but others are intended directly for users. For example, the MyBaseOptions role is typically assigned to users so that they can edit some of their own contact details by using ECP. To get a list of Exchange roles, you can run the Get-ManagementRole cmdlet from an Exchange 2010 server.
A management role group specifies who can do something. This nomenclature is a little confusing. You might think that membership is defined in the role itself, but the role group defines membership. Role groups are actually Windows universal security groups that are stored in the Exchange security group’s organizational unit (OU) in AD. You can see the group membership by using a tool such as the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in. However, you should not edit the group membership manually. Group memberships contain custom attributes that would likely be damaged if you were to edit them by using the Active Directory Users and Computers snap-in.
A scope defines a set of objects on which a role can take action. For example, you might define the scope of a given role to be an individual mailbox database, an Exchange server, or an OU. Scopes can grant read or write access to a set of objects.
The role assignment ties these definitions together. When you assign a user to a particular role, the user gains the ability to execute the commands that are defined in that role against a particular scope. For example, you might grant an administrator the organization management role to allow a user to execute a wide variety of commands on a wide variety of Exchange objects throughout the Exchange organization. You might, then, assign a different user a more limited role, such as the ability to conduct organization-wide mailbox searches.
It’s important to remember that RBAC assignments are applied by using their own mechanism, not by using the standard Windows ACL mechanism. Usually, if you’ve defined multiple sets of permissions on a resource, the most restrictive set of permissions is applied. But when you apply RBAC, a user gets the union of all the RBAC role entries to which the user has access. For example, if you assign Joe User two different RBAC roles, Joe User will be able to use the cmdlets that are specified in either of the defined roles, not only those that belong to the most restrictive set.
Figure 1 illustrates the relationship between these components. Microsoft refers to this arrangement as the Triangle of Power—an apt name, considering the way in which the elements are related.
Figure 1: Triangle of Power
The scope, role, and role group assignments are linked by the role assignment itself. Microsoft recommends that you first define the scope, then the role, then the role group, and, finally, the role assignment. That’s the pattern that I’ll follow here.
RBAC Scopes
Role scopes define where a role can be applied. Exchange itself defines a wide range of scopes. To help you grasp the full range, I’ll first draw a distinction between read and write scopes. The difference is easy to understand: If an object is within the read scope of a role, role holders can read the object. The concept is the same for the write scope.
Each role has separate read and write scopes for recipients and for configuration. That is, every role has a recipient read scope, a recipient write scope, a configuration read scope, and a configuration write scope. The built-in Exchange management roles have implicit scopes. For example, the Public Folders management role has an implicit recipient read and write scope of Organization and an implicit configuration read and write scope of OrganizationConfig. That tells us that someone who holds that role can read and modify both recipient and configuration objects anywhere in the organization. (Remember: The role itself can restrict which specific cmdlets and parameters can be used.)
You can also set your own explicit scopes, either by using a predefined set of scopes that are built into Exchange or by defining your own. The predefined scopes are as follows and can be used only for setting the recipient read and write scopes:
- Organization (global to the organization)
- Self (allows access only to the current user’s mailbox)
- MyDistributionGroups (allows access only to distribution groups owned by the current user)
Custom scopes are much more interesting. Exchange supports three different types of custom scopes:
- OU (allows recipient objects in a given OU to be modified)
- Recipient filter (lets you specify a recipient filter that selects the objects that the role holder is allowed to see or change)
- Configuration (allows you to grant read or write access to a subset of objects from the configuration container)
Configuration scopes are the most complex of the three. They allow you, for example, to define a mailbox database scope that restricts role holders to a subset of mailbox databases in an organization. Configuration scopes can be based on filters that dynamically select the objects that should be included, or they can be based on lists, in which you specify the exact set of objects that should be included. Perhaps an example will help clarify the difference. The following cmdlet defines a configuration scope based on a database filter:
New-ManagementScope -Name "HQ Databases" -DatabaseRestrictionFilter \\{Name -eq "HQ*" \\}
This scope will automatically include all databases in the organization whose names begin with HQ.
Suppose that you then wanted to define a scope that would apply only to three specific hub servers in your HQ site. You could use a list scope to do this:
New-ManagementScope -Name "HQ Hub Servers" -ServerList HQ-HT01,HQ-HT02,HQ-HT-SPARE
You’ve probably figured out by now that you create scopes by using the New-ManagementScope cmdlet. You can get a list of the defined scopes by using the Get-ManagementScope cmdlet, and you remove scopes that aren’t assigned to any role assignments by using the Remove-ManagementScope cmdlet.
Roles
After you’ve defined the scopes you want to use, the next step is to define the roles themselves. Each role defines a set of cmdlets and parameters that role holders are allowed to use. Let’s take a look at a simple role.
The MyDisplayName role allows users to change their own display names through ECP. If you use the Get-ManagementRoleEntry cmdlet, you can see the specific entries that are assigned to this role, as Figure 2 shows.
Figure 2: Entries assigned to the MyDisplayName role
This role contains two entries: one for Set-User and one for Set-Mailbox. Why are there two? Because both of these cmdlets can be used to change the user’s display name. In general, you’ll see multiple similar role entries for any operation that can be accomplished in more than one way. Many cmdlets (Set-OWAVirtualDirectory, for one, comes to mind) are specific to a single function, so you won’t typically see overlapping entries for them.
What about a more complex role? The Unified Messaging role is a decent example. Figure 3 shows part of what the output from Get-ManagementRoleEntry "Unified Messaging\*" looks like. There are a few noteworthy things about this management role. First, you can see that there are entries for each of the UM-related cmdlets. Holders of this role can execute any cmdlet that’s defined in a role entry within the role, so it makes sense that all the UM-related cmdlets would have entries here so that role holders can use them. Additionally, each role entry specifies a set of parameters to which the user should have access.
Figure 3: Partial output from Get-ManagementRoleEntry "Unified Messaging*"
It’s probably more interesting to dig into a single management role entry to see how the parameters are specified for a given cmdlet. Take a look at the output from the following cmdlet:
Get-ManagementRoleEntry "Unified Messaging\Set-UMDialPlan" | select parameters | fl
Figure 4 shows the output. Notice that some of these parameters are actually arguments to the cmdlet, whereas others (such as Confirm, DomainController, and Debug) are common PowerShell switches that aren’t specific to this individual cmdlet. One of the beauties of RBAC is that you can control access down to the individual parameters passed to the cmdlet. We’ll see shortly how to actually do that.
Figure 4: Output from Get-ManagementRoleEntry "Unified MessagingSet-UMDialPlan" | select parameters | fl
EMS interprets the role entries when it’s asked to initialize for a particular user. It loads cmdlets that have a role entry defined for one of the roles that the user holds. If a given cmdlet doesn’t have any matching role entries, it isn’t loaded. EMC and ECP hide or disable the user interface for cmdlets that are found to be missing during initialization.
With such a variety of built-in roles, the odds are good that you’ll be able to find a role that meets your needs. If not, you can create a new role that’s based on one of the existing roles, then customize the role by adding or removing cmdlets and parameters.
You can create new custom roles only via inheritance, not from scratch. Because of this restriction, a child role can never have more rights than its parent, though you are free to remove things from the parent. For example, let’s say that you wanted to define a custom role that would allow holders to change only the UM PIN for selected mailboxes. The simplest way to do this would be to create a new custom role based on the existing UM Mailboxes role, then remove the cmdlets that you didn’t want.
To do this, first create the new custom role by using the New-ManagementRole cmdlet, as follows:
New-ManagementRole -name "UM PIN Reset" -parent "UM Mailboxes"
After you create the new custom role, if you run Get-ManagementRoleEntry on the new role, you’ll see that it has access to several cmdlets that you don’t want, including Set-UMMailbox, Set-ADServerSettings, and Set-MailboxJunkEmailConfiguration. This isn’t necessarily bad because each role entry restricts users to a specific set of items. However, if you want to pare things down, you can do so by removing almost all the role entries. You can’t remove all of them! If you do, the role loses its ability to do anything and becomes useless. This cmdlet does the trick:
Get-ManagementRoleEntry "UM PIN Reset\*" | where \\{$_.Name -ne "Get-UMMailboxPIN"\\} | Remove-ManagementRoleEntry
This example leaves the Get-UMMailboxPIN role entry intact. It’s important to know that you can’t have a role entry for a Set cmdlet without also having the corresponding Get cmdlet. In this case, that means that you’ll have to restore the Set-UMMailboxPIN role entry, as follows:
Add-ManagementRoleEntry "UM PIN Reset\Set-UMMailboxPIN" -parameters LockedOut, NotifyEmail, Pin, SendEmail
Role Groups
Role groups themselves are very straightforward. The Get-RoleGroup cmdlet shows you the eleven built-in role groups, which Table 1 describes.
Table 1: Exchange Server 2010 Built-in Role Groups
If you follow Microsoft’s recommended workflow for using RBAC, the step for defining role groups is easy to follow because you’ve already defined the “where” (the scope) and the “what” (the role and its role entries) that you want to use. Defining the group lets you specify who is able to work in the defined scope on the defined target objects.
You can create a new role group by using (no surprise) the New-RoleGroup cmdlet. This cmdlet requires that you specify the group name and one or more roles that you want the group to have. If you want, you can also define a scope for the group. This lets you define a role and assign it to a role group that has a more restrictive scope than the original role definition. However, remember that users in a role group will get access to all the cmdlets and parameters that are allowed under any role in the group. If you don’t assign a scope, the default scope for the role is used.
To extend our UM example a bit, you can create a role group for UM PIN management in the following way:
New-RoleGroup "UM PIN Managers" -roles "UM PIN Reset"
You can assign members to the role group by using the members switch:
New-RoleGroup "UM PIN Managers" -roles "UM PIN Reset" -members paulr,brianh,davidw
You can also use aliases or SMTP addresses to assign membership.
Role Assignments
Adding the members switch to the New-RoleGroup cmdlet creates management role assignments. This is a useful shortcut. Following the Microsoft model, though, what if you want to create the management role assignments separately?
When you create a management role assignment, you bind a role to a scope and also to a role group or to a user. You can see this for yourself by doing the following: Issue the Get-ManagementRoleAssignment cmdlet, use the New-ManagementRoleAssignment cmdlet to create a new assignment, then run Get-ManagementRoleAssignment again. You’ll notice that a new entry is appended. Exchange 2010 SP1 includes 164 management roles. So when you create new assignments, you see them tacked onto the bottom of the list.
The built-in role assignments all have names that follow a simple pattern: Role-Role Group (e.g., Message Tracking-Records Management). You can use the Get-ManagementRoleAssignment cmdlet to see the details of a specific role assignment by passing its name. The resulting output will show you which roles are assigned, what scopes are in effect for the assignment, and some other useful information about the role assignment.
Sometimes, it’s easiest to create role assignments when you create a new role group. However, one of the nicest things about Exchange 2010 RBAC is that it includes a very large set of roles and role assignments, so you can almost always use the predefined entries as a starting point.
Role Assignment Policies
Besides the ability to explicitly give users role assignments, you can also give them the appropriate level of access by relying on a little-understood Exchange 2010 feature called role assignment policies. A role assignment policy specifies the role assignments that you want to apply to a group of users. Exchange includes a default role assignment policy that grants users the right to modify most of their own personal information; this default policy applies the MyBaseOptions, MyContactInformation, MyProfileInformation, MyVoiceMail, MyTextMessaging, MyDistributionGroupMembership, and MyDistributionGroups roles to all users.
The beauty of this system is that, by adding or removing roles to this policy, you control the user options in ECP. You can also define new role assignment policies and change the default role assignment policies that are applied to users so that they get exactly the access you want them to have. To do this, create a role assignment policy and use the Set-RoleAssignmentPolicy cmdlet together with the IsDefault switch. Additionally, you assign management role assignment policies to new mailboxes when you create or enable them through the New-Mailbox or Enable-Mailbox cmdlets. You can also use Set-Mailbox to assign a new role assignment policy to an existing mailbox.
RBAC and Exchange Control Panel
So far, I’ve focused on using EMS to manipulate RBAC objects. In Exchange 2010 SP1, Microsoft added support for some RBAC operations in ECP. This is a great step forward because it makes RBAC much easier to access and to manage for the average administrator.
When you log on to ECP by using an account that has the Organization Management role, you’ll see a link labeled Roles & Auditing in the navigation pane. Click this link, and you’ll see two unfamiliar icons at the top of the details pane for Administrator Roles and User Roles, as Figure 5 shows. The controls for Administrator Roles let you view, modify, and define role groups for administrative access. The corresponding controls for User Roles give you the same power for user-facing role assignment policies.
Figure 5: Exchange Control Panel interface for viewing and managing roles and role assignments
Notice that I didn’t say anything about roles or scopes here. ECP doesn’t include a facility for creating or managing roles or scopes. You can create new role groups by using the existing set of roles and scopes. Also, roles or scopes that you create yourself by using EMS will appear here. That makes ECP a good tool for simple RBAC management tasks, but you can’t use it as a 100-percent replacement for EMS.
When you create a new role group, you specify a name, the set of roles that the role group should contain, and the members that you want to include in the role group, as Figure 6 shows. You can’t remove cmdlets or change the assigned set of parameters here because you can’t change the contents of the roles that you’re assigning. Therefore, using this functionality requires some forethought to decide what abilities you want members of the role group to have.
Figure 6: Creating a new role group in Exchange Control Panel
You can use the User Roles tools in ECP to modify the default role assignment policy or to create a new one. Either way, when you modify or create a role assignment policy, you see a dialog box that resembles the one in Figure 7. You can control which of the built-in “My” roles users can access. In this example, I’ve created a policy that lets users manage most aspects of their own account, but not of their distribution group ownership or of their membership. Additionally, some capabilities that I don’t want users to have access to (such as the ability to manage text messaging settings) are disabled. This is similar to the default policy that Microsoft uses for its own Exchange operations.
Figure 7: Page for modifying a role assignment policy
A New Way to Manage
RBAC is a long-established technology that will, nonetheless, be completely new to many Exchange administrators. It seems quite daunting at first compared with other Exchange technologies. This is partly because Exchange 2010 features such as database availability groups (DAGs) build on a foundation of things we already understand, including mailbox databases. RBAC, however, is mostly new.
The time and effort that you invest in learning how to make effective use of RBAC will pay off in increased security, easier management, and a much more flexible permissioning model. I expect that as RBAC becomes better understood, we’ll see it become one of the most important drivers for Exchange 2010 adoption.
