4. Introduction to 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 its users to change their own
phone numbers in the Global Address List (GAL), must they be allowed to
change their display names as well?
By
implementing RBAC, a feature first implemented in Exchange Server 2010,
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 management
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. Note that it is not absolutely necessary to define
management role groups; management roles can be assigned directly to
users, but this practice is discouraged because it is difficult to
manage.
• 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—A
designation that 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—An
entity that 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 grouping of all the pieces that define what a user is
allowed to do in an Exchange Server 2013 environment, whether he or she
is 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 the following:
• 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.
Run the cmdlet Get-ManagementRole to see the complete list.
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 2013 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
2013. 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 administrators) can create
security principals in AD, whereas another (Exchange Server
administrators) 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 the environment
because it can be extremely difficult to implement correctly. Under
this model, AD administrators need to create new users but cannot configure the Exchange Server attributes on the objects. Exchange Server administrators can configure the attributes but cannot
create new accounts. Under the split permissions model, Exchange Server
administrators 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 administrators can still create and manage Exchange
Server–specific objects, such as transport rules, distribution groups,
and so on. To implement a split-permissions model, the option Apply
Active Directory Split Permissions Security Model to the Exchange
Organization must be selected during Exchange 2013 setup.
The Benefits of RBAC
One
of the goals that Microsoft worked toward with the design and creation
of Exchange Server 2013 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 access control list
(ACL)-based model of previous Exchange Server versions.
Employees
can now track the status of messages that they have sent, create and
manage their own distribution lists, and update certain aspects of
their account information, such as their Contact Location (address) and
Contact Numbers (work, fax, home, and mobile phone numbers).
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; and then view the properties of the OU.
On the Object tab, deselect the Protect Object from Accidental Deletion
check box.
