Windows Vista
Windows 7
Windows Azure
Windows Server
Windows Phone
Windows Server

Administering an Exchange Server 2013 Environment (part 6) - Introduction to Role Based Access Control

2/18/2014 3:12:08 AM

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



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.


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.

Other -----------------
- Windows Server 2012 Administration : Managing Printers with the Print Management Console (part 3) - Using the Print Management Console
- Windows Server 2012 Administration : Managing Printers with the Print Management Console (part 2) - Adding New Printers as Network Shared Resources
- Windows Server 2012 Administration : Managing Printers with the Print Management Console (part 1) - Configuring the Print Management Console
- Windows Server 2008 : Configuring Server Core after Installation (part 4) - Setting the Time, Date, and Time Zone , Joining a Domain
- Windows Server 2008 : Configuring Server Core after Installation (part 3) - Logging Off, Shutting Down, and Rebooting
- Windows Server 2008 : Configuring Server Core after Installation (part 2) - Restoring the Command Prompt , Renaming the Computer
- Windows Server 2008 : Configuring Server Core after Installation (part 1) - Installing Server Core
- Microsoft Exchange Server 2010 : Introducing Journaling - Implementing Journaling, Reading Journal Reports
- Microsoft Exchange Server 2010 : Setting Up Transport Rules (part 5) - Creating New Rules with the Exchange Management Shell
- Microsoft Exchange Server 2010 : Setting Up Transport Rules (part 4) - Creating New Rules with the Exchange Management Console
- Microsoft Exchange Server 2010 : Setting Up Transport Rules (part 3) - Selecting Actions
- Microsoft Exchange Server 2010 : Setting Up Transport Rules (part 2) - Selecting Conditions and Exceptions
- Microsoft Exchange Server 2010 : Setting Up Transport Rules (part 1) - Transport Rules Coexistence Between Exchange 2007 and 2010 , Transport Rules and Server Design Decisions
- Microsoft Systems Management Server 2003 : Analysis and Troubleshooting Tools - Using SMS Trace (part 2)
- Microsoft Systems Management Server 2003 : Analysis and Troubleshooting Tools - Using SMS Trace (part 1) - Obtaining SMS Trace
- Microsoft Systems Management Server 2003 : Analysis and Troubleshooting Tools - Using SMS Service Manager
- Microsoft Systems Management Server 2003 : Analysis and Troubleshooting Tools - Status Message Process Flow
- Microsoft Systems Management Server 2003 : Analysis and Troubleshooting Tools - Working with Status Message Queries
- Microsoft Systems Management Server 2003 : Filtering Status Messages (part 2) - Status Filter Rules
- Microsoft Systems Management Server 2003 : Filtering Status Messages (part 1) - Configuring Status Reporting Properties
Most view of day
- Securing Your SharePoint and Windows Azure Solutions : Configuring Shared Access Permissions for BLOB Storage - Using Claims-Based Authentication
- Troubleshooting Hardware, Driver, and Disk Issues : How to Use Built-In Diagnostics (part 4)
- SharePoint 2013 Request Management (part 2) - Request Management Administration
- Exchange Server 2007 : Migrating from Windows 2000 Server to Windows Server 2003 (part 1) - Beginning the Migration Process
- Windows Phone 8 : The Multimedia Experience - History, Displaying New Content
- SQL Server 2012 : Running SQL Server in A Virtual Environment - MANAGING CONTENTION
- Deploying Applications Using Group Policy and SCCM 2007 : Deploying Applications Using SCCM 2007 (part 1)
- Adobe Flash Catalyst CS5 : Round-trip editing with Adobe Illustrator and Adobe Photoshop
- SQL Server 2012 : Data Architecture (part 1) - Information Architecture Principle, Database Objectives
- System Center Configuration Manager 2007 : Reporting Configuration (part 2) - Copying ConfigMgr Classic Reports to SQL Reporting Services, Report Categories
Top 10
- Microsoft Lync Server 2013 : Director Troubleshooting (part 3) - Synthetic Transactions,Telnet
- Microsoft Lync Server 2013 : Director Troubleshooting (part 2) - DNS Records, Logs
- Microsoft Lync Server 2013 : Director Troubleshooting (part 1) - Redirects, Certificates
- Microsoft Lync Server 2013 : Administration of the Director Role (part 4) - Services Management, Client Version Filter
- Microsoft Lync Server 2013 : Administration of the Director Role (part 3) - Topology Status
- Microsoft Lync Server 2013 : Administration of the Director Role (part 2) - Ports,Firewall Rules
- Microsoft Lync Server 2013 : Administration of the Director Role (part 1) - Services
- Microsoft Lync Server 2013 : Configuring the Director (part 2) - Web Services Ports,Reverse Proxy
- Microsoft Lync Server 2013 : Configuring the Director (part 1) - SRV Records, Web Services FQDN Overrides
- Sharepoint 2013 : SharePoint Designer 2013 (part 2) - Locking Down SharePoint Designer
Windows XP
Windows Vista
Windows 7
Windows Azure
Windows Server
Windows Phone
2015 Camaro