Windows 7 / Getting Started

---

Role Based Access Control

One of the administrative shortcomings of Exchange Server has been the ability to control precisely who can administer what. Granting a group of administrators the necessary permissions to create mailboxes anywhere in an Exchange Server environment might be practical for a small organization, but what about a large company with a worldwide presence? Do you actually want the support staff in one country to administer (and have access to) the mailboxes in another country? Do you actually want your tier 1 help desk personnel, staffed by junior administrators, to have the same access to Executive mailboxes as they do to Sales? And what about your user community? Just because an organization wants to allow their users to change their own phone number in the GAL, must they be allowed to change their display name as well? Controlling administrative permissions to this level of granularity was often desired but difficult (or impossible) to implement with the permissions model in Exchange Server 2007-so Microsoft threw it out and started over.

In Exchange Server 2010, by implementing Role Based Access Control (RBAC), Microsoft has empowered organizations to not only dictate precisely who can access what, but also where. With RBAC, the permission to perform tasks is assigned to specific roles. Administrators and users are assigned to appropriate roles, and through their membership in the role, they acquire the necessary permissions to perform the desired task. This does not only apply to administrators; RBAC also controls the extent to which end users can self-administer their own accounts.

The RBAC permissions model consists of four components:

• Management role group-A special universal security group (USG) in Active Directory (AD) that can be composed of mailboxes, users, other USGs, and other role groups. All members of a role group are assigned the same set of roles, and members are added to a management role group to assign the desired permissions.
• Management role-A container that holds management group entries. Management roles define the actual tasks that can be performed by members of the associated role group. A management role entry is a cmdlet (a specialized command in the PowerShell environment) and its parameters that are added to a management role. This process grants rights to manage or view the objects associated with that cmdlet.
• Management role assignment-Links a management role to a management role group. This grants the users assigned to the group the ability to perform the actions assigned to the role group.
• Management role scope-Defines the scope of influence that a role assignment has. A management role scope can include servers, organizational units, filters on server or recipient objects, and more.

And thus, we achieve the ability to control who (via management role group and management role assignment) can do what (via management role and management role entries) and where (via management role scope). Exchange Server administration can now be as granular or as broad as the needs of the organization mandate, and with RBAC, organizations can more closely align the permissions assigned to users and administrators to the roles they actually hold.

Understanding Management Role Groups

A management role group is a universal security group that is part of the RBAC permissions model. A management role group simplifies the assignment of management roles to a user or group of users. Management roles are assigned to the entire role group, so all members of a particular role group share the same set of roles.

Role groups are assigned both administrator and specialist roles. These define the major administrative tasks in Exchange Server and enable an organization to assign a broader set of permissions to a group of administrators, specialists, or even end users.

Understanding Management Roles

As previously stated, management roles act as logical groupings of all the pieces that define what a user is allowed to do in an Exchange Server 2010 environment, whether they are a senior Exchange Server architect, a junior help desk employee, or an end user.

Microsoft has provided dozens of built-in management roles that meet the basic needs of most environments. These roles cannot be modified, nor can the management role entries that are configured for them, but the scope can be modified. Some examples of built-in management roles include

• Reset Password
• Transport Rules
• Move Mailboxes

By adding users or groups of users to these management roles, the permissions needed to perform tasks can easily be assigned. So, if you want your tier 1 support staff to manage recipients and change their passwords, you would assign the Mail Recipients and Reset Password roles to the role group.

Although management roles can be directly assigned to users, it is recommended that role groups and role assignment policies are utilized to simplify the permissions model.

Understanding Management Role Assignments

A management role assignment is the connector between a role and a role assignee. A role assignee can be a role group, role assignment policy, user, or universal security group. Before a role can take effect, it must be assigned to a role assignee.

By adding, removing, or modifying a role assignment, administrators can control what permissions are given to other administrators and users. This effectively enables (or disables) management capabilities for the user.

Role assignments come in two flavors: Regular role assignments and Delegating role assignments.

Regular role assignments enable the assignee to access the management role entries made available by the associated management role. Management role entries are aggregated (combined), so if an assignee has several role assignments, all of the associated management roles are given. Delegating role assignments do not give access to manage features; instead, they give a role assignee the ability to assign the specified role to other role assignees.

Understanding Management Role Scopes

A management role scope enables administrators to define the specific range of impact or influence that a management role has once a management role assignment has been created. By applying a role scope, the role assignee can modify only the objects contained within the scope.

Every management role, whether built in or custom, is governed by its associated management role scope. Scopes can be inherited from the management role, specified as a predefined relative scope for a particular management role assignment, or created using custom filters and added to a management role assignment. Those that are inherited from management roles are called implicit scopes, whereas the predefined and custom scopes are called explicit scopes.

There are two types of management role scope:

Regular role scopes are not exclusive. They determine where, in AD, objects can be viewed or modified by users assigned the associated management role. To put it simply, the management role dictates what objects a user can create or modify, and the management role scope dictates where the user can create or modify them. Regular scopes can be either implicit or explicit scopes.

Exclusive role scopes behave similarly to regular scopes, except that they provide the ability to deny users access to objects if the users aren't assigned a role associated with the exclusive scope. All exclusive scopes are explicit scopes.