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.
Shared Versus Split Permissions Models
Both AD and
Exchange Server environments require administrators with specialized
knowledge to administer them. In some organizations, the responsibility
for managing these two environments is shared by the same personnel.
Other organizations have separate departments for managing AD and
Exchange Server.
Exchange Server
2010 enables organizations to use either a shared permissions or a split
permissions model. By default, the shared permissions model is
deployed.
Shared Permissions Model
Organizations that want to
use a shared permissions model don’t need to change anything because
this is the default model used in Exchange Server 2010. There is no
separation of the management of Exchange Server and AD objects from
within the Exchange Server management tools: the Exchange Management
Console, the Exchange Management Shell, or the Exchange Control Panel. Administrators using these tools can
create security principles in AD and manage the configuration of those objects in Exchange Server.
Split Permissions Model
In
the split permissions model, a distinction is made between the creation
of security principals in AD (such as users and security groups) and
the configuration of those objects. Proper implementation of a split
permissions model allows organizations to minimize the risk of
unauthorized access to the network by limiting the ability to create
objects to a small group of authorized personnel.
Using this
model, one group of administrators (AD admins) can create security
principals in AD, whereas another (Exchange Server admins) can manage
specific attributes on existing AD objects.
Organizations
desiring to implement a split permissions model should give serious
thought as to whether this model will truly work in their environment.
Under this model, AD admins need to create new users but cannot configure the Exchange Server attributes on the objects. Exchange Server admins can configure the attributes but cannot create new accounts. Under the split permissions model, Exchange Server admins can no longer use any of the following cmdlets:
New-Mailbox or Remove-Mailbox
New-MailUser or Remove-MailUser
New-MailContact or Remove-MailContact
New-LinkedUser or Remove-LinkedUser
Add-MailboxPermission
Add-MailboxFolderPermission
Exchange Server
admins can still create and manage Exchange Server-specific objects,
such as transport rules, distribution groups, and so on.
Configuring Exchange Server 2010 for Split Permissions
To implement a
split permissions model, the Mail Recipient Creation and Security Group
Creation and Membership roles must be assigned to a newly created role
group. This role group contains users who are AD admins. Then, the
assignments between those roles and any role group or universal security
group (USG) that contains Exchange Server admins must be removed.
To perform this task
using the Exchange Management Shell, perform the following steps: (The
Exchange Management Shell commands are in italics.)
1. | Create
a new role group for the AD admins and create regular role assignments
between the new role group and the Mail Recipient Creation and Security
Group Creation and Membership roles.New-RoleGroup "Active Directory Administrators" -Roles "Mail Recipient Creation", "Security Group Creation and Membership"
|
2. | Create a delegating role assignment between the new role group and the Mail Recipient Creation role.
New-ManagementRoleAssignment "Mail Recipient Creation_AD Administrators_Delegating"
-Role "Mail Recipient Creation" -SecurityGroup "Active Directory Administrators" -Delegating
|
3. | Create a delegating role assignment between the new role group and the Security Group Creation and Membership role.
New-ManagementRoleAssignment "Security Group Creation and Membership_Org Mgmt_Delegating"
-Role "Mail Recipient Creation" -SecurityGroup "Active Directory Administrators" -Delegating
|
4. | Add the Active Directory admins to the new role group.
Add-RoleGroupMember "Active Directory Administrators" -Member <user to add>
|
5. | Replace the delegate list on the new role group so that only members of the role group can add or remove members:
Set-RoleGroup "Active Directory Administrators" -ManagedBy "Active Directory Administrators"
Note
Individuals who are
members of the Organization Management role group, or those assigned
the Role Management role either directly or indirectly, can bypass this
security check. To prevent Exchange Server administrators from adding
themselves to the new role group, the role assignment between the Role
Management role and any Exchange Server administrator must be removed
and assigned to another group.
|
6. | Find all the regular and delegating role assignments to the Mail Recipient Creation role.
Get-ManagementRoleAssignment -Role "Mail Recipient Creation"
|
7. | Remove
all the regular and delegating role assignments to the Mail Recipient
Creation that aren’t associated with the new role group or any other
role groups, USGs, or direct assignments that will remain.
Remove-ManagementRoleAssignment <Mail Recipient Creation role assignment to remove>
|
8. | Find all of the regular and delegating role assignments to the Security Group Creation and Management role.
Get-ManagementRoleAssignment -Role "Security Group Creation and Membership"
|
9. | Remove
all the regular and delegating role assignments to the Security Group
Creation and Management that aren’t associated with the new role group
or any other role groups, USGs, or direct assignments you want to keep.
|
Remove-ManagementRoleAssignment <Security Group Creation and Membership role assignment to remove>
Benefits of RBAC
One
of the goals that Microsoft worked toward with the design and creation
of Exchange Server 2010 is the capability to decrease support costs.
Early in the process, it realized that one way to significantly reduce
the administrative overhead in an environment was to empower users to
perform specific tasks for themselves, rather than go through the
time-consuming and resource-intensive process of requesting assistance
to complete relatively minor changes.
Granting users the
administrative rights to perform certain low-level tasks, while still
preventing them from accessing (and potentially damaging) configuration
settings that could impact the entire organization was extremely
difficult, if not impossible, using the ACL-based model of previous
Exchange Server versions.
Now with RBAC, employees
can be given permission to track the status of messages that they have
sent, create and manage their own distribution lists, and update certain
aspects of their account information.
RBAC focuses on
the effective and efficient distribution of administrative permissions.
In previous versions of Exchange Server, granting help desk personnel
(for example) the ability to create new mailboxes in one site gave them
(by default) the ability to create new mailboxes anywhere in the
environment. Locking down these permissions to one specific site was
time-consuming and complicated—and there are many
different scenarios that had to be identified, evaluated, and resolved
before administrators could be sure they had matched the appropriate
personnel with the appropriate access.
Another example of
the benefits of RBAC is in the area of eDiscovery—granting permissions
to a group of users (such as members of the HR department) to view the
contents of a particular set of mailboxes (such as those located in the
Marketing OU).
Using RBAC,
administrators can grant the necessary access to allow the members of
the HR department to review the mailboxes of the Marketing users but not those in sales (located in another OU).
These permissions can
easily be delegated using RBAC for the duration of the discovery period
and then removed until needed again.
Note
When creating a new
OU in a Windows 2008 Active Directory environment, you might notice a
new and welcome feature; when naming the OU, the option to Protect
Container from Accidental Deletion is present and automatically
selected. This places an explicit Deny permission on the object for the
group “everyone,” preventing accidental deletion of the object. To
remove this (for intentional deletion), go to Active Directory Users and
Computers, select View \ Advanced Features; then view the properties of
the OU. Under the Object tab, you can see the Protect Object from
Accidental Deletion check box and de-select it.
