Module 1: Role Based Access Control

Information in this document, including URL and other Internet Web site references, is subject to change without notice. Unless otherwise noted, the example companies, organizations, products, domain names, email addresses, logos, people, places, and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, e-mail address, logo, person, place or event is intended or should be inferred. Complying with all applicable copyright laws is the responsibility of the user. These materials are intended for distribution to and use only by Microsoft Premier Customers. Use or distribution of these materials by any other persons is prohibited without the express written permission of Microsoft Corporation. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.

2010 Microsoft Corporation. All rights reserved.

Microsoft, Active Directory, Windows, Windows NT, and Windows Server are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.

The names of actual companies and products mentioned herein may be the trademarks of their respective owners.

Contents
MODULE 1: ROLE BASED ACCESS CONTROL ................................................................................................ 5 SECTION 1: OVERVIEW OF EXCHANGE SERVER ACCESS CONTROL.............................................................................. 6 Exchange Server Management Roles in an Organization ...................................................................... 7 Access Control in Exchange Server 2003 ................................................................................................ 8 Access Control in Exchange Server 2007 ................................................................................................ 9 Challenges of Exchange Server Access Control .................................................................................... 12 Access Control in Exchange Server 2010 .............................................................................................. 14 Access Control in Exchange Server 2010 SP1 ....................................................................................... 16 RBAC and Active Directory Domain Services ........................................................................................ 17 Permissions Models in Exchange Server 2010 SP1 ............................................................................... 19 Authorization Manager Model ............................................................................................................ 22 Leveraging Role Based Access Control ................................................................................................. 24 Section 1 Review .................................................................................................................................. 26 SECTION 2: MANAGEMENT ROLES.................................................................................................................... 27 Overview of the Management Role ..................................................................................................... 28 Management Role Entries ................................................................................................................... 30 Built-In Administrative Management Roles ......................................................................................... 32 Built-In User-Level Management Roles ................................................................................................ 37 Built-In Unscoped Top-Level Management Roles ................................................................................ 39 Managing the Exchange Management Roles ...................................................................................... 41 Section 2 Review .................................................................................................................................. 45 SECTION 3: MANAGEMENT ROLE GROUPS ......................................................................................................... 46 The Default Universal Security Group Implementation ....................................................................... 47 What Are Role Groups?........................................................................................................................ 49 Built-In Role Groups ............................................................................................................................. 50 Linked Role Groups .............................................................................................................................. 52 Managing Role Groups ........................................................................................................................ 54 Section 3 Review .................................................................................................................................. 55 SECTION 4: MANAGEMENT ROLE SCOPES .......................................................................................................... 56 What Are Management Role Scopes? ................................................................................................. 57 Scope Container Hierarchy................................................................................................................... 58 Exclusive Scopes ................................................................................................................................... 59 Managing Scopes ................................................................................................................................. 61 Section 4 Review .................................................................................................................................. 63 SECTION 5: ROLE ASSIGNMENTS AND ROLE ASSIGNMENT POLICIES......................................................................... 64 What Are Role Assignment Policies? ................................................................................................... 65 Managing Role Assignments and Role Assignment Policies ................................................................ 67 Discussion: How Do the RBAC Elements Work Together?.................................................................... 68 Test Case Scenario Using the RBAC Features ....................................................................................... 70 Section 5 Review .................................................................................................................................. 74 SECTION 6: TROUBLESHOOTING RBAC ............................................................................................................. 75

Troubleshooting RBAC ......................................................................................................................... 76 Diagnostic Logging .............................................................................................................................. 78 Section 6 Review .................................................................................................................................. 82 Lab 1A: Allowing a Group of Users to Create Distribution Lists ........................................................... 83 Lab 1B: Configuring Split Permissions .................................................................................................. 84 Module 1 Summary.............................................................................................................................. 85

Module 1: Role Based Access Control

Introduction
One of the most difficult aspects of managing a Microsoft Exchange Server organization is controlling access to resources and management operations. Administrators have to strike a balance between allowing the minimum level of access that allows everyone to do their jobs while preventing them from accessing sensitive materials or exclusive operations that are not part of their responsibilities. Exchange Server 2010 introduces a role based access control (RBAC) model for access control. This module describes RBAC in Exchange Server 2010.

Objectives
After completing this module, you will be able to:

Explain RBAC in Exchange Server 2010. Implement and manage RBAC in an Exchange 2010 infrastructure. Troubleshoot and diagnose issues related to RBAC.

Section 1: Overview of Exchange Server Access Control

Introduction
To better understand the problems administrators face, this section introduces common terminology used in the access control technology, followed by some common scenarios describing the access control challenges Exchange Server administrators face. This section also introduces the RBAC model used in Exchange Server 2010, including new features available with Exchange Server 2010 Service Pack (SP1).

Objectives
After completing this section, you will be able to:

Describe access control through various Exchange Server versions. Describe the Exchange Server RBAC model for access control.

Exchange Server Management Roles in an Organization

The level of access control that allows users to successfully carry out the tasks related to a management role varies from narrow for end users to broad for organization administrators. The built-in management roles found in an Exchange Server organization are:

Administration:

View-only administrator Help desk Organization administrator Department administrator Specialist Records manager

Self-service:

Manager Assistant End user Distribution group owner

Access Control in Exchange Server 2003

To simplify administration of permissions, previous Exchange Server versions provided solutions that were based on management roles. Exchange Server 2003 introduced rudimentary management roles based on security settings required to accomplish tasks associated with those roles. These roles were then applied as a collection of standardized permissions at either the organization or administrative group level. The following roles are applied to users and groups through the Delegation wizard in Exchange System Manager:

Exchange Full Administrator. Exchange Full Administrator permissions allow a user or group to fully administer Exchange Server computer information and to modify permissions on the Exchange Server container and its hierarchy. Exchange Administrator. Exchange Administrator permissions allow a user or group to fully administer Exchange Server computer information. They do not grant the right to change permissions on Exchange Server objects in the Exchange Server container. Exchange View Only Administrator. Exchange View Only Administrator permissions allow a user or group to view Exchange Server configuration information.

Access Control in Exchange Server 2007

To improve the implementation of management roles, Exchange Server 2007 introduced a richer role-based model with five new roles. Four of these roles correspond directly to Exchange Server security groups that are similar to the built-in Windows Server operating system security groups. The following roles are applied to users and groups using the Exchange Management Console and the Exchange Management Shell.

Exchange Organization Administrators. Exchange Organization Administrators permissions provide administrators with full access to all Exchange Server properties and objects in the Exchange Server organization. Users who are members of the Exchange Organization Administrators group have the highest level of permissions in the organization. Successful execution of tasks that affect an entire organization requires membership in this group. Exchange Recipient Administrators. Exchange Recipient Administrators permissions allow administrators to modify any Exchange Server property on an Active Directory Domain Services (AD DS) user, contact, group, dynamic distribution list, or public folder object. Exchange View-Only Administrators. Exchange View-Only Administrators permissions provide read-only access to the entire Exchange Server organization tree in the Active Directory configuration container, and read-only access to all the Windows domain containers that have Exchange Server recipients. Exchange Public Folder Administrators. Exchange Public Folder Administrators permissions allow administrators to manage all the public folders. This administrator role includes the extended right to create top-level public folders. Members of this role can create and delete public folders, and manage public folder settings such as replicas, quotas, age limits, administrative permissions, and client permissions.

Administrators can also mail-enable public folders, but they cannot modify mail recipient-related properties on public folders, such as proxy addresses. This role was not introduced until Exchange Server 2007 SP1. Exchange Server Administrators. Exchange Server Administrators permissions allow access to only local server Exchange Server configuration data, either in AD DS or on the physical computer on which Exchange Server 2007 is installed. Users assigned the Exchange Server Administrators role have permissions to administer a particular server, but do not have permissions to perform operations that have global impact in the Exchange Server organization.

In addition to these management roles, Exchange Server 2007 provided cmdlets specifically for manipulating Active Directory permissions of Exchange Server attributes on objects and containers. These cmdlets delegate permissions for managing recipient and configuration objects.

Split Permissions Model

The shared permissions model provided by the default configuration of Exchange Server and AD DS does not generally mesh well with the security and administrative roles defined by most organizations. Normally, the administrators who create user accounts are not the same administrators who manage mailboxes. Most organizations, especially large businesses, use separate administrators for Exchange Server and AD DS. This separation of duties requires careful delegation of administrative tasks so that distinct operational boundaries can be maintained without compromising security boundaries. This is known as a split permissions model. Only administrators with Exchange Organization Administrators permissions can manage Exchange Server recipient data in addition to managing Exchange Server configuration data. To manage object creation and modification within the domain partition, these administrators also require membership in at least the Account Operators security group, which is not granted by default. While this level of access may not be a problem for some small organizations, large companies usually delegate just enough access control to allow administrators to carry out their tasks. To accomplish this goal, access control must be applied at the attribute level.

Attribute-Level Access Control

To use Exchange Server 2003 management tools to manage Exchange Server-related attributes on objects within the domain naming context, the modify permission must be granted to a user or group to which at least the Exchange Administrators role has been delegated. Do this by setting the security descriptor on the object that has these attributes. A security descriptor contains two access control lists (ACLs). An ACL is a list of user or security group objects that have been granted or denied access to a resource or object. ACLs allow granular permissions to be applied to an entire object, a set of an objects

properties, or an individual property of an object. There are two types of access control lists maintained within an objects security descriptor: Discretionary ACLs. Discretionary ACLs identify the users and groups that are assigned or denied access permissions on an object. System ACLs. System ACLs identify the users and groups that you want to audit when they successfully access or fail to access an object.

You can apply permissions directly to an object, or to a domain partition or organizational unit (OU) container. When you apply permission at the domain or OU container level, all objects within the domain or container inherit the permission.

Property Sets
A property set is a group of attributes that enables access control to a subset of an objects properties by setting one access control entry rather than setting an entry on each individual property. An access control entry is an entry in an objects discretionary ACL that grants permissions to a user or group. In Exchange Server 2003, the Exchange Server schema extension added Exchange Server-related mail recipient attributes to the built-in Personal Information and Public Information Active Directory property sets. Many Active Directory administrators do not want to assign permissions to administrators using these property sets because they provide access to non-Exchange Server-related attributes that are also part of these property sets. Exchange Server 2007 takes advantage of property sets by creating two new sets called Exchange Information and Exchange Personal Information. These new property sets are used exclusively for Exchange Server, and they allow simplified permissions delegation for management of Exchange Server mail recipient data. The property sets allow you to delegate access control to the Exchange Recipient Administrators group.

Challenges of Exchange Server Access Control

Administrators face significant challenges when delegating permissions for Exchange Server tasks. Exchange Server 2003 provides only one role that allows administrators to make modifications. Exchange Server 2007 provides only three roles that allow modifications. You cannot customize built-in roles provided by Exchange Server 2003 and Exchange Server 2007. You cannot create new roles. Exchange Server 2007 roles are too broad for some decentralized IT environments. Access to organizational level operations cannot be broken down into smaller units of access. Access control management is complex. To set granular permissions and assign administrative scope, you have to customize object and container ACLs, which is complex and prone to error. Tools such as discretionary ACLs, system ACLs, and the Active Directory Service Interfaces Editor (ADSI Edit) are not user friendly and open up possibilities for mistakes that may yield undesirable results. Successful delegation of access control requires knowledge of several hundred Exchange Server properties and how they relate to administrative tasks. Exchange Server attributes are scattered across multiple property sets, which can make it difficult to scope administrative rights. Use of Exchange Server-specific property sets in Exchange Server 2007 help solve the issue, but there is still no simple out-of-the-box solution.

Exchange Server administrators name access control management as one of their main work tasks. Permissions are focused on objects and not on tasks. The granularity of permissions in Exchange Server is based on ACLs that are applied to an Active Directory object. This limits the ability to set different permissions for two similar tasks. For example, to allow the Set-Mailbox cmdlet but deny the MoveMailbox cmdlet for the same user context. Excessive privileges are required for some Exchange Server operations. Executing certain Exchange Server tasks requires the delegation of permissions that typically exceed the expected level of access for the administrator that would be responsible for these tasks. Companies are forced to trust administrators through business processes that cannot be enforced by the system. Object access auditing and delegated permissions reporting are difficult. There is no support for self-service management. Many organizations would like to decrease the burden on administrators by shifting the burden of maintaining incidental information and administrative functions to employees. Hosted Exchange Server providers need a solution for delegating self-administration tasks to users, and organization administrative tasks to administrators.

Access Control in Exchange Server 2010

Exchange Server 2010 introduces the RBAC model for access control. The goal of RBAC is to: Consistently enforce access control according to the management roles assigned to each user. Prevent control from being bypassed except by users who already have high-level administrative access.

The following new access control features for RBAC allow you to manage access to Exchange Server administrative operations. Management roles based on administrative tasks: Exchange Server 2010 provides several new default management roles based on administrative tasks associated with those roles. Roles are assigned to users and groups to grant them rights to manage or view the objects associated with the tasks for the roles. New roles for self-management are available to help administrators easily delegate control of personal information to end users.

Customized roles: You can create and customize new management roles as needed to meet the level of access control an organization requires.

Management role scopes:

You can apply scopes to a management role assignment to limit the role holder to specific objects that they can control. Use scopes to limit access to servers, organizational units, and recipient objects.

Organizational wide enforcement: Access control enforcement operates through all Exchange Server administrative interfaces and applies to the entire organization.

Access control at the task level: For customized roles, you can add or remove parameters for individual Exchange Server tasks to further define the level of access control. Task-level access is visible in the administrative interfaces so users are aware of the access they are allowed.

Auditing and reporting: Auditing allows you to track user access to objects and to monitor the actions users performed. Reporting allows you to identify users who have access control and their levels of access.

Access Control in Exchange Server 2010 SP1

Exchange Server 2010 SP1 introduces the following improvements to the RBAC access control feature: Active Directory split permissions model. Exchange Server 2010 SP1 offers Active Directory split permissions in addition to RBAC split permissions. It leverages the Exchange Windows Permissions group. You can assign Exchange Server tasks to Exchange Server administrators, and Windows administration tasks to Windows administrators. It is available during Installation/Updates. Use the following command:

Setup.com /preparead /activedirectorysplitpermissions:true

The split permissions model is described in detail in the following sections. Database scoping. In Exchange Server 2010, administrators were restricted to server lists. In Exchange Server 2010 SP1, you can restrict administrators to a set of databases, which increases flexibility with permissions. Database scoping controls edits, creation, and mailbox moves. Exchange Best Practices Analyzer reporting. The Exchange Best Practices Analyzer reporting capabilities were improved. For example, you can now view missing default values, missing containers, and empty required role groups. Exchange Control Panel improvements. The Exchange Control Panel includes GUI enhancements that improve your ability to manage management role groups and role assignment policies.

RBAC and Active Directory Domain Services

To understand the split permissions model, you need to understand how the RBAC permissions model in Exchange Server 2010 integrates with AD DS. The RBAC model regulates who can perform which actions, and on which objects those actions can be performed. In Exchange Server 2010, all tasks that are performed on Exchange Server objects must be performed through the Exchange Management Console, the Exchange Management Shell, or the Exchange web administrative interface. Each of these management tools uses RBAC to authorize the tasks. RBAC is a component that exists on every Exchange server. RBAC checks that a user performing an action is authorized to do so. If the user has authorization, it then verifies that the user is authorized to perform the action against the specific object being requested. If the user is approved for the object, RBAC allows the action to proceed. If approval is not authorized at any stage, RBAC rejects the users request. If RBAC allows an action to proceed, the action is performed in the context of the Exchange Trusted Subsystem and not the users context. The Exchange Trusted Subsystem is a highly-privileged universal security group (USG) that has read and write access to every Exchange Server-related object in the organization. It is also a member of the Administrators local security group and the Exchange Windows Permissions USG, which enables Exchange Server to create and manage Active Directory objects.
Warning: The Exchange Trusted Subsystem USG must not be removed from any security groups and must not be removed from the ACL of any object. Exchange Server relies on this USG to function properly. By removing this USG from any group or object ACL you could cause irreparable damage to your organization.

If a user is authorized by RBAC to perform an action in the Exchange Server management tools, the user can perform the action regardless of his or her Active Directory permissions. Conversely, if a user is an Enterprise administrator in AD DS but is not authorized to perform an action such as creating a new mailbox in the management tools, the action will not succeed because the user does not have the required RBAC permissions.
Important: The RBAC permissions model does not apply to the Active Directory Users and Computers management tool, and you cannot use this tool to manage the Exchange Server configuration. Therefore, a user who may have access to modify some attributes on Active Directory objects must use the Exchange Server management tools and must be authorized by RBAC to manage Exchange Server attributes.

Permissions Models in Exchange Server 2010 SP1

Exchange Server 2010 SP1 still supports the implementation of the shared permissions model and the split permissions model: The shared permissions model is the default model for Exchange Server 2010 that does not separate the management of Exchange Server and Active Directory objects from within the Exchange Server management tools. The split permissions model allows enabled administrators to create security principals.

Exchange Server 2010 SP1 now supports the implementation of two different split permissions models: The RBAC modeled split permissions model is a flexible solution for customers who have less rigid requirements for split permissions, or who need to allow high-level administrators to share the AD Administrator and Exchange Administrator roles. The Active Directory split permissions model is stricter and is intended for customers who must ensure a full split between the actions that an Exchange Administrator can perform and those that an AD Administrator can perform.

Exchange Server 2010 SP1 setup was updated to allow for easy switching between the RBAC modeled and the Active Directory split permissions models.

Switching to the Shared Permissions Model

You can configure an Exchange Server 2010 organization for shared permissions if it was previously set for split permissions. The procedure to switch to shared permissions is different depending on whether the organization is currently using RBAC split permissions or Active Directory split permissions.

If the following are true, then the organization uses Active Directory split permissions: The Microsoft Exchange Protected Groups OU exists. The Exchange Windows Permissions security group is located in the Microsoft Exchange Protected Groups OU. The Exchange Trusted Subsystem security group is not a member of the Exchange Windows Permissions security group. There are no regular management role assignments using the Mail Recipient Creation or the Security Group Creation and Membership management roles.

If the following are true, then the organization uses RBAC split permissions: The Microsoft Exchange Protected Groups OU does not exist. The Exchange Trusted Subsystem security group is a member of the Exchange Windows Permissions security group. The Mail Recipient Creation and the Security Group Creation and Membership management roles are not assigned to the Organization Management and Recipient Management role groups, but are assigned to role groups that include only Active Directory administrators as members.

If the organization was never configured for split permissions, you do not need to perform the following procedures. By default, Exchange Server 2010 is configured for shared permissions.

Switching from Active Directory Split Permissions to Shared Permissions

To switch from Active Directory split permissions to Exchange Server 2010 shared permissions, you must rerun Exchange Server Setup to disable Active Directory split permissions in the organization, and then create role assignments between a role group and the Mail Recipient Creation and the Security Group Creation and Membership roles. In the default shared permissions configuration, the Organization Management role group contains each of these roles. Because of this, you would use the Organization Management role group for this procedure. Role assignments to the Mail Recipient Creation and the Security Group Creation and Membership roles are not automatically created when you switch from Active Directory split permissions to shared permissions. If role assignments were customized prior to enabling Active Directory split permissions, those customizations are left intact.
Note: The setup.com command in the following procedure modifies AD DS. You must use an account with the proper permissions to make these changes. This account might not be the same account that has permissions to create role assignments using the New-ManagementRoleAssignment cmdlet. Use the account, or accounts, with the permissions necessary to successfully complete each step in this procedure.

To switch from Active Directory split permissions to shared permissions, do the following: 1. To disable Active Directory split permissions, in a Windows command shell, run the following command from the Exchange Server 2010 SP1 installation media.
setup.com /PrepareAD /ActiveDirectorySplitPermissions:false

2. In Exchange Management Shell, run the following cmdlets to add regular role assignments between the Mail Recipient Creation and the Security Group Creation and Management roles, and the Organization Management and the Recipient Management role groups.
New-ManagementRoleAssignment "Mail Recipient Creation_Organization Management" -Role "Mail Recipient Creation" -SecurityGroup "Organization Management"

New-ManagementRoleAssignment "Security Group Creation and Membership_Org Management" -Role "Security Group Creation and Membership" -SecurityGroup "Organization Management"

New-ManagementRoleAssignment "Mail Recipient Creation_Recipient Management" -Role "Mail Recipient Creation" -SecurityGroup "Recipient Management"

After you run these cmdlets, wait for the changes to replicate across the organization. The amount of time this takes depends on the Active Directory site topology. After allowing time for replication, we recommend that you restart the Exchange Server 2010 servers in the organization to force them to pick up the new Active Directory access token with the updated permissions.

Switching from RBAC Split Permissions to Shared Permissions

To switch from RBAC split permissions to Exchange Server 2010 shared permissions, you must assign the Mail Recipient Creation and the Security Group Creation and Membership roles to a role group that is also assigned to the Mail Recipients role and has Exchange Server 2010 administrators as members. In the default shared permissions configuration, the Organization Management role group contains each of these roles. Because of this, you use the Organization Management role group for this procedure.

Authorization Manager Model

RBAC relies on Microsoft Windows PowerShell version 2.0 and the Windows Remote Management 2.0 (WinRM) service to provide remote PowerShell through Internet Information Services (IIS). The RBAC authorization code is incorporated into this implementation, and RBAC executes access control through the remote PowerShell server-side runspace. Applications integrated with the Windows Server 2008 operating system and AD DS use the built-in features of the operating system to perform authorization. Windows Server 2008 supports two authorization mechanisms: Windows ACL-based impersonation model Roles-based Authorization Manager

Authorization Manager is composed of a set of component object model (COM)-based runtime interfaces that allows applications to easily manage and verify a clients requests to perform application operations. Authorization Manager simplifies application access control administration in line-of-business applications, and it enables flexible and dynamic authorization decisions. Typically, you define access control models with the terms subject, resources, and permissions. A subject is often a user operating upon resources. Access is controlled by a set of permissions that allows the subject to perform specific operations on the resource. Access control administration rarely deals directly with these constructs; it generally involves managing collections of subjects, resources, and permissions. You normally manage subjects, or users, in groups, but you manage resources in application-specific collections such as directories and OUs. Permissions may be granted

directly, but are often grouped into higher level permissions such as Full Control. These collections enable authorization management in environments that have many subjects, resources, and permissions. Application administrators must use these collections to generate an authorization policy for the application so that each subject has the appropriate permissions to use the application resources. Traditional resource manager applications store authorization policies with the resources to which the policies apply. For example, the resource manager stores an ACL on a file and logically associates it with the file. In the Authorization Manager model, authorization policy data is stored separately from the object in an authorization policy store. An application identifies the operations and tasks that the application can perform and declares them in the authorization store when the application is installed. Administrators manage the authorization policy by defining roles in terms of the tasks and operations that are required to perform a job in an organization. The definitions of roles, tasks, and operations, and the assignment of users and groups to the roles are stored in the authorization store. Applications query the authorization policy at run time to confirm that a client is authorized to perform a requested operation on a resource. The Exchange Server 2010 RBAC implementation uses AD DS to store the authorization policy store in the form of configuration objects.

Leveraging Role Based Access Control

RBAC simplifies access control administration and provides better manageability in enterprise environments by allowing permissions to be managed in terms of user job roles. You can distill the level of access control that is achievable down to three elements: What. The user sees only the tasks made available by RBAC based on the management role assignments. Management roles are discussed in Section 2. Who. The user is assigned to management role groups, which are collections of tasks (cmdlet and parameter definitions) that are required by the user to carry out their management responsibilities. Management role groups are discussed in Section 3. Where. The user can only use the tasks that they can see on the objects that fall under the scope that was used in the management role assignments. Management role scopes are discussed in Section 4.

RBAC allows administrators to specify access control in terms of the organizational structure of a company. RBAC does this by creating a new object called a role. You assign a user to a role so that the user can perform a job function. Unlike groups, however, a role defines the authorization permissions on some set of resources. In the RBAC model, the administrator uses the role to manage permissions and assignments. For example, a company may create a role called Sales Manager that has the permissions that sales managers need to perform their jobs. When sales managers are hired, they are assigned the Sales Manager role and instantly have all required permissions for that job. When they leave the position of sales manager, they are removed from the Sales Manager role and no longer have Sales Manager access. Since the role allows access to be granted in terms of a companys organizational model, it is more intuitive and natural for administrators to specify access control.

In most environments, once the role permissions are established, changes to a roles permissions are rare compared to changes in assignments to the role. This means that administrators have to set up roles such as Employee, Manager, and Administrator, but once roles are created, administrators manage membership in the roles and not permissions on objects. Additionally, RBAC controls both the administrative tasks that can be performed and the extent to which users can self-administer themselves.

Section 1 Review

Answer the questions listed on the slide above.

Section 2: Management Roles

Introduction
This section describes how management roles work within the Exchange Server 2010 RBAC access control model.

Objectives
After completing this section, you will be able to: Describe the function of management roles within the RBAC model. Describe and use the different types of management roles.

Overview of the Management Role

Exchange Server management role configuration objects exist in a parent and child hierarchy. The top of the hierarchy consists of built-in management roles that are provided by Exchange Server 2010 as default roles. They are created automatically during setup, and you can assign them to administrators and users either directly or by group membership. These roles are read-only, and administrators cannot change them. However, you can determine the scope of built-in management roles when they are assigned to users. The built-in management roles divide into three groups as described later in this section: administrative, user-level and unscoped top-level. The tasks within the groups are divided into logical groupings for specific functions. You can create custom management roles as needed. When creating a custom management role, start by copying an existing role. You can copy from built-in roles or other custom roles. The new role becomes a child of the role from which you copied, and it inherits all the role entries from the parent role. Consider the management role hierarchy represented in the following tree diagram:
Mail Recipients Tier2 HelpDesk Tier1 HelpDesk

In this example, a custom management role called Tier2 HelpDesk was created as a child of the built-in management role called Mail Recipients. A second custom management role called Tier1 HelpDesk was created as a child of Tier2 HelpDesk. Tier2 HelpDesk

inherits the role entries from Mail Recipients, and Tier1 HelpDesk inherits the role entries from Tier2 HelpDesk. Custom roles appear in the directory as child objects of the parent management role from which they were cloned. Customize a child role by removing the role entries inherited from its parent until the role suits the access control needs of the users to which the role is assigned. Child roles can never grant a higher level of access control than the parent role from which they were created. Each management role also has a specific role type that you cannot change. The role type defines the base purpose for the role. The role type is copied from the parent role when a child role is created. The management roles configuration objects are stored in the directory under the CN=RBAC parent container in the CN=Roles container.

Management Role Entries

Every management role must have at least one management role entry. An entry consists of a task that you want to make available to the user. The task can be a cmdlet along with any of its parameters, the name of a Windows PowerShell script, or permissions for application impersonation. Management role entries are stored as an element of the msExchRoleEntries attribute on management role objects. This multivalued string attribute holds the information that defines the tasks available to the given management role. Management role entries are managed using RBAC management tasks from the Exchange Management Shell.

Controlling Task Access with Management Role Entries

If a task does not appear as an entry on a management role, that task is not available to the user by using that role. Likewise, if a parameter for a given cmdlet is not included as an entry, the parameter is not accessible for that cmdlet by using that role. If a user attempts to execute a task that is not included as an entry on any management role assignment that applies to the user, the task fails. The manner in which the task fails varies according to the management interface the user uses.

Inheriting Management Role Entries

A management role entry must be included as an entry on a parent role to be inherited as an entry on any child roles. Generally, child roles provide a weaker level of access control than their parent roles because you remove cmdlets and parameters from the child role until you reach the desired level of access control.

You can add entries that were previously removed from a child role as long as they are still present in the parent role. However, you cannot add an entry to a child role that is not already an entry on the parent. This applies to cmdlets and their parameters. For example, suppose that the Tier2 HelpDesk parent role was modified to remove the Set-Mailbox cmdlet. This means that you cannot change the Tier1 HelpDesk child role to include the Set-Mailbox cmdlet. Furthermore, suppose that the Set-Mailbox cmdlet was included as an entry on the Tier2 HelpDesk parent role, but the Database parameter was not included in the entry. You cannot add the Database parameter to the Tier1 HelpDesk child role. Because you cannot add management role entries to child roles if the entries do not appear in their parent roles, and because roles are based on specific role types, you must carefully choose the parent role to copy when you want to create a new customized role.

Built-In Administrative Management Roles

Administrative management roles provide access control for management tasks of an organization. These tasks range from server administration to recipient management. The following table describes the default built-in administrative management roles that come with Exchange Server 2010.
Management Role Name Active Directory Permissions Address Lists Audit Logs Cmdlet Extension Agents Database Availability Groups Description Enables administrators to configure Active Directory permissions. Enables administrators to manage address lists, global address list (GALs), and offline address lists. Enables administrators to manage audit logs. Enables administrators to manage cmdlet extension agents. Enables administrators to manage database availability groups (DAGs) in an organization. Administrators who are assigned this role either directly or indirectly are the highest level administrators responsible for the high availability configuration. Enables administrators to manage database copies on individual servers. Enables administrators to create, manage, mount, and dismount mailbox and public folder databases on individual servers. Enables administrators to restore mailboxes and DAGs. Enables administrators to create and manage distribution groups and distribution group members. Enables administrators to manage edge synchronization and subscription configuration between Edge Transport servers and Hub Transport servers. Enables administrators to manage email address policies.

Database Copies Databases Disaster Recovery Distribution Groups Edge Subscriptions

E-Mail Address Policies

Management Role Name Exchange Connectors

Description Enables administrators to manage connectors that are not Send and Receive connectors in an organization. These connectors include routing group connectors and delivery agent connectors. Enables administrators to create, import, export, and manage Exchange Server certificates on individual servers. Enables administrators to manage Exchange Server configuration on individual servers.

Exchange Server Certificates Exchange Servers

Exchange Virtual Directories Enables administrators to manage Microsoft Outlook Web App, Microsoft Exchange ActiveSync, the offline address book, Autodiscover, Windows PowerShell, and the Web administration interface virtual directories on individual servers. Federated Sharing Information Rights Management Journaling Legal Hold Mailbox Import Export Mailbox Search Enables administrators to manage cross-forest and crossorganization sharing. Enables administrators to manage the Information Rights Management features of Exchange Server. Enables administrators to manage journaling configuration. Enables administrators to configure whether data within a mailbox should be retained for litigation purposes. Enables administrators to export information from, and import information to, mailboxes. Enables administrators to search the content of one or more mailboxes.

Mail Enabled Public Folders Enables administrators to configure whether individual public folders are mail-enabled or mail-disabled. This role enables you to manage the email properties of public folders only. It does not enable you to manage non-email properties of public folders. To manage non-email properties of public folders, you need to be assigned the Public Folders role. Mail Recipient Creation Enables administrators to create mailboxes, mail users, mail contacts, distribution groups, and dynamic distribution groups in an organization. You can combine this role with the Mail Recipients role to enable the creation and management of recipients. This role does not enable you to mail-enable public folders. To mailenable public folders, you must be assigned the Mail Enabled Public Folders role. If an organization maintains a split permissions model in which recipient creation is performed by a different group than that which performs recipient management, assign the Mail Recipient Creation role to the group that performs recipient creation, and the Mail Recipients role to the group that performs recipient management. Mail Recipients Enables administrators to manage existing mailboxes, mail users, mail contacts, distribution groups, and dynamic distribution groups in an organization. You cannot use this role to create these recipients, but you can combine it with the Mail Recipient Creation role to enable the creation and management of recipients. This role does not enable you to manage mail-enabled public folders or distribution groups. To manage mail-enabled public folders, you must be assigned the Mail Enabled Public Folders role. To manage distribution groups, you must be assigned the

Management Role Name

Description Distribution Groups role. If an organization maintains a split permissions model in which recipient creation is performed by a different group than that which performs recipient management, assign the Mail Recipient Creation role to the group that performs recipient creation, and the Mail Recipients role to the group that performs recipient management.

Mail Tips Message Tracking Migration Monitoring

Enables administrators to manage MailTips. Enables administrators to track messages. Enables administrators to migrate mailboxes and mailbox content into or out of a server. Enables administrators to monitor the Microsoft Exchange services and component availability in an organization. In addition to administrators, you can use this role with the service account used by monitoring applications to collect information about the state of the Exchange servers. Enables administrators to move mailboxes between servers in an organization, and between servers in different organizations. Enables administrators to manage Client Access server settings. Enables administrators to manage organization-wide settings. Organization configuration that can be controlled with this role include the following: Whether MailTips are enabled or disabled for the organization. The URL for the managed folder home page. The Microsoft Exchange recipient primary Simple Mail Transfer Protocol (SMTP) address and alternate email addresses. The resource mailbox property schema configuration. The Help URLs for the Exchange Management Console and for Outlook Web App.

Move Mailboxes Organization Client Access Organization Configuration

This role does not include the permissions included in the Organization Client Access or Organization Transport Settings role. Organization Transport Settings Enables administrators to manage organization-wide transport settings such as system messages, site configuration, and other organization-wide transport settings. This role does not enable you to create or manage transport Receive or Send connectors, queues, hygiene, agents, remote and accepted domains, and transport rules. To create or manage each of the transport features, you must be assigned the following roles: Receive connectors Send connectors Transport queues Transport hygiene Transport agents Remote and accepted domains Transport rules

POP3 and IMAP4 Protocols Enables administrators to manage Post Office Protocol version 3 (POP3) and Internet Message Access Protocol version 4 (IMAP4) configurationsuch as authentication and connection settingson individual servers.

Management Role Name Public Folder Replication Public Folders

Description Enables administrators to start and stop public folder replication. Enables administrators to manage public folders. This role does not enable you to manage whether public folders are mail-enabled or to manage public folder replication. To mail-enable or -disable a public folder, you must be assigned the Mail Enabled Public Folders role. To configure public folder replication, you must be assigned the Public Folder Replication role.

Receive Connectors Recipient Policies Remote and Accepted Domains Retention Management Role Management

Enables administrators to manage transport Receive connector configuration, such as size limits on an individual server. Enables administrators to manage recipient policies such as provisioning policies. Enables administrators to manage remote and accepted domains. Enables administrators to manage retention policies. Enables administrators to manage management role groups, role assignment policies, management roles, role entries, assignments, and scopes. Users assigned to this role can override the role group Managed By property, configure any role group, and add or remove members to or from any role group.

Security Group Creation and Membership

Enables administrators to create and manage USGs and their memberships. If an organization maintains a split permissions model in which USG creation and management is performed by a different group than that which manages Exchange servers, assign this role to that group.

Send Connectors Support Diagnostics

Enables administrators to manage transport Send connectors. Enables administrators to perform advanced diagnostics under the direction of Microsoft support services. Caution: This role type grants permissions to cmdlets and scripts that should only be used under the direction of Microsoft support services.

Transport Agents Transport Hygiene Transport Queues Transport Rules UM Mailboxes UM Prompts Unified Messaging

Enables administrators to manage transport agents. Enables administrators to manage antivirus and anti-spam features. Enables administrators to manage transport queues on an individual server. Enables administrators to manage transport rules. Enables administrators to manage the Unified Messaging configuration of mailboxes and other recipients. Enables administrators to create and manage custom Unified Messaging voice prompts. Enables administrators to manage Unified Messaging servers. This role does not enable you to manage Unified Messagingspecific mailbox configuration or Unified Messaging prompts. To manage Unified Messaging-specific mailbox configuration, use the UM Mailboxes role. To manage Unified Messaging prompts, use

Management Role Name

Description the UM Prompts role.

UnScoped Role Management User Options

Enables administrators to create and manage unscoped top-level management roles in an organization. Enables administrators to view the Outlook Web App options of a user in an organization. You can use this role to help users diagnose problems with their configurations. Enables administrators to view all of the non-recipient Exchange Server configuration settings in an organization. Examples of configurations that are viewable are server configuration, transport configuration, database configuration, and organization-wide configuration. You can combine this role with the View Only Recipients role to enable viewing every object in an organization.

View Only Configuration

View Only Recipients

Enables administrators to view the configuration of recipients, such as mailboxes, mail users, mail contacts, distribution groups, and dynamic distribution groups. You can combine this role with the View Only Configuration role to enable viewing every object in the organization.

Built-In User-Level Management Roles

User-level management roles enable users with assigned RBAC roles to access selfmanagement tasks. For example, users assigned to the MyOptions role can modify their user properties such as their addresses, phone numbers, and display names. Users assigned to the MyDistributionGroups role can create new distribution groups, add members to those groups, remove distribution groups that they created, and perform similar tasks. The following table describes the default built-in user-level management roles that come with Exchange Server 2010.
Management Role Name MyBaseOptions MyContactInformation MyDiagnostics MyDistributionGroupMembership Description Enables users to view and modify the basic configuration of their mailboxes and associated mailbox settings. Enables users to modify their contact information. This information includes their addresses and phone numbers. Enables users to view the calendar diagnostic log for their mailbox calendars. Enables users to view and modify their memberships in distribution groups in an organization, provided that these distribution groups allow manipulation of group membership. Enables users to create, modify, and view distribution groups and modify, view, remove, and add members to distribution groups that they own. Enables users to modify their names. Enables users to view their retention tags, and to view and modify their retention tag settings and defaults.

MyDistributionGroups

MyProfileInformation MyRetentionPolicies

Management Role Name MyTextMessaging MyVoiceMail

Description Enables users to create, view, and modify their text messaging settings. Enables users to view and modify their voicemail settings.

Built-In Unscoped Top-Level Management Roles

Unscoped top-level management roles are a special type of management role that grants access to customized scripts and non-Exchange Server cmdlets. Regular management roles provide access only to Exchange Server cmdlets. If you need to provide access to non-Exchange Server cmdlets that run on an Exchange server, or to publish a script that users can run, you must be added to an unscoped role. Unscoped roles are top-level roles because when they are first created without deriving from a parent role, they exist at the same level as the built-in management roles. Unlike regular management roles, you cannot scope these roles to a specific target. Unscoped roles are always organization wide. This means that someone who is assigned an unscoped role can modify any object in the Exchange Server 2010 organization. Scripts and cmdlets made available through unscoped roles should be thoroughly tested to verify what they modify. Additionally, assign unscoped roles carefully. You can assign unscoped roles to role assignees such as role groups, management roles, users, and USGs. You cannot assign them to management role assignment policies. Designate the role entries that you add to unscoped roles as unscoped top-level role entries. Although you cannot add Exchange Server cmdlets as management role entries on unscoped roles, you can include them in scripts added as role entries. This allows you to create custom scripts that perform Exchange Server tasks that you can then assign to users. Unscoped management roles are useful when, for example, a user must perform a highly privileged task that normally falls outside his or her administrative level and where crafting a new management role or role group would be problematic. You can create a script that performs this specific function, add it to an unscoped role, and then assign the

unscoped role to the user. The user can then perform only the specific function provided by the script. The Organization Management role group does not, by default, have permissions to create or manage unscoped role groups. This prevents unscoped role groups from mistakenly being created or modified. The Organization Management role group can delegate the Unscoped Role Management management role to itself and other role assignees.

Managing the Exchange Management Roles

Use the following cmdlets to manage the Exchange Server management roles: Get-ManagementRole. View management role objects and attributes. New-ManagementRole. Create new custom management roles based on built-in management roles. Remove-ManagementRole. Remove custom management roles that are no longer in use.

Additionally, use the following cmdlets to manage the management role entries: Get-ManagementRoleEntry. View management role entries that were configured on management roles. Add-ManagementRoleEntry. Add management role entries to an existing management role. Set-ManagementRoleEntry. Change the available parameters on an existing management role entry. Remove-ManagementRoleEntry. Remove existing management role entries.
Note: Most cmdlets include common parameters that control how the cmdlet behaves for the purposes of risk mitigation, troubleshooting, and debugging. Because the use of these parameters varies only slightly from one cmdlet to the next, and are not specific to Exchange Server cmdlets, the descriptions for these parameters are not included in this section.

The syntax is for the Get-ManagementRole cmdlet is:

Get-ManagementRole [-Identity <RoleIdParameter>] [-Cmdlet <String>] [-CmdletParameters <String[]>] [-RoleType <RoleType>] [-Organization <OrganizationIdParameter>] [-DomainController <Fqdn>] [<CommonParameters>]

Get-ManagementRole [-Identity <RoleIdParameter>] [-Script <String>] [-ScriptParameters <String[]>] [-Organization <OrganizationIdParameter>] [-DomainController <Fqdn>] [<CommonParameters>]

Get-ManagementRole -Identity <RoleIdParameter> -Recurse <SwitchParameter> [-RoleType <RoleType>] [-Organization <OrganizationIdParameter>] [-DomainController <Fqdn>] [<CommonParameters>]

Get-ManagementRole -Identity <RoleIdParameter> -GetChildren <SwitchParameter> [-RoleType <RoleType>] [-Organization <OrganizationIdParameter>] [-DomainController <Fqdn>] [<CommonParameters>]

The Get-ManagementRole cmdlet facilitates gathering and viewing information about management roles based on different circumstances. Using one or more parameters as input, you can retrieve management roles based on the following conditions: All management roles or a specific management role by name. Specific types of management roles. Management roles that have a specific cmdlet or cmdlet parameter as an entry. Unscoped top-level management roles that have a specific script or script parameter as an entry. Custom management roles that were copied from a specific built-in management role.

A user must be granted access through role assignment before running this task. By default, role assignment grants the required access to the following role groups: Organization Management View-Only Organization Management Delegated Setup

Hygiene Management

The following table describes the main parameters for the Get-ManagementRole cmdlet.
Parameter Name Identity Description Specifies the name of the management role you want to view. If the name contains spaces, you must enclose it in quotation marks. The Identity parameter takes both wildcard and pipeline input values. GetChildren Returns a list of all the management roles that were created based on the parent management role specified by the Identity parameter. Returns only the immediate child management roles of the parent management role. You can only use this parameter with the Identity parameter and only when the Identity parameter takes a specific management role name as input. The GetChildren parameter requires no input value. Recurse Returns a list of all the management roles that were created based on the parent management role specified by the Identity parameter. It returns the management role specified in the Identity parameter, its child management roles, and their children. You can only use this parameter with the Identity parameter and only when the Identity parameter takes a specific management role name as input. The Recurse parameter requires no input value. Cmdlet Returns a list of all management roles that include the specified cmdlet name as an entry. The Cmdlet parameter takes wildcard input values. CmdletParameters Returns a list of all management roles that include the specified parameter name. If you specify multiple parameter names, only the management roles that include all of the specified names are returned. You can specify more than one parameter name by separating each name with a comma. Script ScriptParameters Returns a list of all management roles that include the specified script name. Returns a list of all management roles that include the specified script parameter name. If you specify multiple parameter names, only the management roles that include all of the specified names are returned. You can specify more than one parameter name by separating each name with a comma. RoleType Returns a list of management roles that match the specified role type. The valid role types are: ActiveDirectoryPermissions, AddressLists, ApplicationImpersonation, AuditLogs, CentralAdminManagement, CmdletExtensionAgents, Custom, DatabaseAvailabilityGroups, DatabaseCopies, Databases, DataCenterOperations, DisasterRecovery, DiscoveryManagement, DistributionGroupManagement, DistributionGroups, EdgeSubscriptions, EmailAddressPolicies, ExchangeConnectors, ExchangeServerCertificates, ExchangeServers, ExchangeVirtualDirectories, FederatedSharing, GALSynchronizationManagement, HelpdeskRecipientManagement, InformationRightsManagement, Journaling, LawEnforcementRequests, LegalHold, MailboxSearch, MailEnabledPublicFolders, MailRecipientCreation, MailRecipients, MailTips, MessageTracking,

Parameter Name

Description Migration, Monitoring, MoveMailboxes, MyBaseOptions, MyContactInformation, MyDiagnostics, MyDistributionGroupMembership, MyDistributionGroups, MyMailSubscriptions, MyOptions, MyProfileInformation, MyRetentionPolicies, MyTextMessaging, MyVoiceMail, OrganizationClientAccess, OrganizationConfiguration, OrganizationManagement, OrganizationTransportSettings, PartnerDelegatedTenantManagement, POP3AndIMAP4Protocols, PublicFolderReplication, PublicFolders, ReceiveConnectors, RecipientManagement, RecipientPolicies, RecordsManagement, RemoteAndAcceptedDomains, ResetPassword, RetentionManagement, RoleManagement, SecurityGroupCreationAndMembership, SendConnectors, Supervision, SupportDiagnostics, TransportAgents, TransportHygiene, TransportQueues, TransportRules, UMMailboxes, UmManagement, UMPromptManagement, UMPrompts, UmRecipientManagement, UnifiedMessaging, UnScoped, UnScopedRoleManagement, UserOptions, ViewOnlyConfiguration, ViewOnlyOrganizationManagement, ViewOnlyRecipients

Organization

The Organization parameter is not available in on-premise installations.

Important: The DomainController parameter is an optional parameter on multiple cmdlets that specifies the fully qualified domain name (FQDN) of a domain controller to use when accessing data in AD DS. The DomainController parameter is not required unless you need to read or write information from a specific domain controller instead of from a random domain controller.

Section 2 Review

Answer the questions listed on the slide above.

Section 3: Management Role Groups

Introduction
This section describes how management role groups work within the Exchange Server 2010 RBAC access control model.

Objectives
After completing this section, you will be able to: Describe the function of management role groups within the RBAC model. Describe and use the different types of management role groups.

The Default Universal Security Group Implementation

Exchange Server 2010 allows an initial level of RBAC functionality by adding user accounts as members of one or more of the default USGs. This ensures that users have a basic level of access control so that they can carry out the tasks related to their roles.

Exchange Server Installation Account

Exchange Server determines USG membership for the Exchange Server installation account used during initial deployment as follows: Creating a new organization. When a new organization is created, Exchange Server automatically adds the account used for setup to the Organization Management role group. Joining an Exchange Server 2003 organization. If Exchange Server 2010 is installed with an existing Exchange Server 2003 organization, Exchange Server 2010 adds the account used for setup to the Exchange Organization Administrators and the Exchange Recipient Administrators USGs. Joining an Exchange Server 2007 organization. If Exchange Server 2010 is installed with an existing Exchange Server 2007 organization, or an existing mixed Exchange Server 2003 and Exchange Server 2007 organization, the account should already be a member of the Exchange Organization Administrators and the Exchange Recipient Administrators USGs so no further action is required. This is because the account must have Exchange Server administrator rights to join the organization.

Membership in the Exchange Organization Administrators and the Exchange Recipient Administrators USGs are required so that you can enable the level of access control necessary to manage the organization.

Preventing Lockout
A lockout occurs when an administrator makes so many changes to access control mechanisms that the administrator can no longer manage the access control components. The following mechanisms prevent lockout and allow recovery from potential lockout scenarios: Administrators cannot remove the last delegating and regular role assignment to the Role Management role in a populated role group. A populated role group is a role group with at least one direct or indirect member. Administrators cannot remove the last delegating role assignment for any role in a populated role group. Administrators cannot remove either the Organization Management or the Delegated Setup role groups. Administrators cannot modify the built-in roles.

The role-to-role group mapping for each of the built-in role groups is provided in the help documentation. If an administrator does manage to delete all of the standard role assignments in a given role group, an administrator with Role Management permissions can recover the mappings by using New-ManagementRoleAssignment cmdlet.

What Are Role Groups?

A management role group is a USG that simplifies management role assignment to groups of users. All of the members of a role group are assignees of the same set of roles that were assigned to the group. Role groups are assigned administrator and specialist roles that define key tasks in Exchange Server 2010. These tasks include organization management, recipient management, and other administrative tasks. Role groups enable you to assign a broad set of permissions to a group of administrators or specialists. When you create a role group using Exchange Server management tasks, you create the USG that holds the members of the role group, and you create the assignments between the role group and the management roles you specify. You can also specify a management scope to apply to the role assignments, and you can add any mailboxenabled accounts that you want to the new role group.
Note: Do not use role groups to control access to end-user mailbox features. To control access to end-user mailbox features, use management role assignment policies.

When a user becomes a member of a role group, the management roles assigned to the role group are assigned to the user. If a user is a member of multiple role groups, the management roles from each role group are aggregated and assigned to the user. Users, USGs, and other role groups can be members of role groups.

Built-In Role Groups

Exchange Server 2010 creates several default built-in role groups during setup. These default role groups provide varying levels of administrative permissions that are necessary for managing any feature of the organization. The following table describes the built-in role groups.
Role Group Delegated Setup Discovery Management Help Desk Hygiene Management Description Allows administrators to deploy previously provisioned 2010 Exchange servers. Allows administrators and users to perform mailbox searches for data that meets specific criteria. Allows users to perform limited recipient management of Exchange Server 2010 recipients. Allows administrators to configure Exchange Server 2010 antivirus and antispam features. Third-party programs that integrate with Exchange Server 2010 can add service accounts to this role group to grant those programs access to the cmdlets required to retrieve data and configure Exchange Server. Allows administrators to have administrative access to the entire organization and to perform almost any task against any Exchange Server object. By default, the user that installs the first Exchange server becomes a member of the Organization Management role group. Allows administrators to manage public folders and databases on 2010 Exchange servers. Allows administrators to have administrative access to create or modify Exchange Server 2010 recipients. Allows users to configure compliance features, such as retention policy tags, message classifications, and transport rules. Allows administrators to have administrative access to the Exchange Server

Organization Management

Public Folder Management Recipient Management Records Management Server

Role Group Management

Description 2010 server configuration. They do not have access to administer recipient configuration.

UM Management Allows administrators to manage the Unified Messaging features in the organization such as Unified Messaging server configuration, properties on mailboxes, prompts, and auto attendant configuration. View-Only Organization Management Allows administrators to view the properties of any object in the organization.

To view a list of role groups, specify the following cmdlet:

Get-RoleGroup

To view the assigned roles of a specific role group and their descriptions, specify the following cmdlet:
Get-RoleGroup <rolegroup> | fl RoleAssignments,description

You can add or remove role assignments to or from most role groups. The only exceptions are role assignments that are necessary for managing RBAC, as follows: You cannot remove any delegating role assignments from the Organization Management role group. You cannot remove the Role Management role from the Organization Management role group.

Built-in role groups are protected from removal when using Exchange Server management tools. The protection does not apply if you are using toolssuch as ADSIEditthat modify Active Directory directly. The built-in role groups are stored in AD DS in the domain-naming context under the Microsoft Exchange Security Groups OU.

Linked Role Groups

Linked role groups are used in organizations that install Exchange Server 2010 in dedicated resource forests but place users in trusted nonlocal forests. Linked role groups create a link between a role group in the Exchange Server forest and a USG in a nonlocal forest. This is useful when the Active Directory user accounts of the Exchange Server administrators do not reside in the same resource forest as Exchange Server. Linked role groups can only be associated with one nonlocal USG. Additionally, you do not need to create a two-way trust between the Exchange Server forest and the nonlocal forest. The Exchange Server forest needs to trust the nonlocal forest, but the nonlocal forest does not need to trust the Exchange Server forest. A linked role group consists of two parts: Linked role group. The linked role group is a container object that associates the nonlocal USG with the management role assignments assigned to the role group. Nonlocal USG. The nonlocal USG contains the members that should be granted the permissions provided by the linked role group.

When creating a linked role group, you need to provide: A domain controller in the nonlocal forest that contains the users you want to manage the Exchange Server forest The USG that contains those users as members. The nonlocal USG name. The credentials required to access the nonlocal forest.

Exchange Server adds the security identifier (SID) of the nonlocal USG to the linked role group. Because the SID is the only identification for the nonlocal USG, we recommend that the nonlocal forest be specified in the name of the role group when you have multiple nonlocal forests in the organization. A linked role group does not contain members. All of the members of that role group are managed using the nonlocal USG. This means you cannot use the role group management cmdlets to add or remove role group members. When you add members to the nonlocal USG, they are given the permissions provided by the linked role group. You cannot change a standard role groupwhich contains its own membersto a linked role group and vice versa. If you want to change a role group from a standard role group to a linked role group, you must create a new linked role group and then replicate the management role assignments that are present on the standard role group to the linked role group. This is also the case for built-in role groups because they are standard role groups. If you want to manage the entire Exchange Server forest from a nonlocal forest, you need to create new linked role groups and then add the management roles that exist on the builtin role groups to the new linked role groups.

Managing Role Groups

Use the following cmdlets to manage role groups: Get-RoleGroup. View role group information. This cmdlet provides a full list of all built-in role groups along with any custom role groups that exist. New-RoleGroup. Create a new role group for RBAC delegation. The new role groups are generated in the Exchange Security Groups OU. Set-RoleGroup. Modify the properties and manage attributes on existing role groups. Remove-RoleGroup. Remove role groups when they are no longer needed. Using this cmdlet removes the role group from AD DS so you can no longer use it. Get-RoleGroupMember. View role group membership. Add-RoleGroupMember. Add a member to a role group. Update-RoleGroupMember. Bulk modify role group membership. Remove-RoleGroupMember. Remove a member from a role group. You can add a user back to a role group by using the Add-RoleGroupMember cmdlet or by simply adding the user to the group within AD DS.

Section 3 Review

Answer the questions listed on the slide above.

Section 4: Management Role Scopes

Introduction
This section describes how management role scopes work within the Exchange Server 2010 RBAC access control model.

Objectives
After completing this section, you will be able to: Describe the function of management role scopes within the RBAC model. Describe and use the different types of management role scopes.

What Are Management Role Scopes?

Management role scopes define the degree of access that users have within a management role. When you apply a scope, the user or group assigned to the role can only modify the objects that are contained within that scope. A scope can be inherited from a management role, specified as an available predefined relative scope, or created as a custom scope using filters. Scopes inherited from management roles are known as implicit scopes. Predefined and customized scopes specified during role assignment are known as explicit scopes. Every management role has one or more scopes. Each role can have up to four scope types, as follows: RecipientReadScope. Specifies which recipient objects the user assigned to the management role can read from a domain-naming context in AD DS. RecipientWriteScope. Specifies which recipient objects the user assigned to the management role can modify in a domain-naming context in AD DS. ConfigReadScope. Specifies which configuration objects the user assigned to the management role can read from the configuration-naming context in AD DS. ConfigWriteScope. Specifies which configuration objects the user assigned to the management role can modify in the configuration-naming context in AD DS.

Recipient objects include mailboxes, distribution groups, mail-enabled users, and other objects. Configuration objects for the purposes of RBAC are limited to servers running Exchange Server 2010. Write scopes used in role assignments can be implicit or explicit, but read scopes can only be implicit.

Scope Container Hierarchy

When processing a request for access control, RBAC aggregates the scopes for all the management role assignments in the users context to verify that access is allowed. For each evaluated management role entry, the scope that provides the widest access is the scope that applies. Exchange Server 2010 uses a scope container hierarchy to establish the precedence of scope types when determining the widest access. Suppose your domain management scopes are as follows:

The Organization scope type provides the widest access because it allows access to every recipient object in the organization. MyGAL is more restrictive because it allows access to only recipient objects that are visible in a specific GAL. Self is even more restrictive because it allows access to only the users recipient object. A pattern of hierarchy emerges from these comparisons because Organization is bigger than MyGAL, and MyGAL is bigger than Self, and so on. Organization is also bigger than OU and CustomRecipientScope. This also emerges as a pattern of containers because Organization can be said to contain MyGAL, OU, and Custom.

Exclusive Scopes

By default, a custom scope enables a role assignee to access a set of objects that match the filters you define. However, they do not actively exclude access to other role assignees who are also assigned the same or equivalent scope through a different role assignment. Any customized scope can access the same objects if the filters on those scopes match the same objects. There might be scenarios in which this behavior is not optimal, as in the case of important personnel such as executives. Because of the multiple ways that you can assign a role, a user could have multiple role assignments for the same management role but with each using a different customized scope. If this is true, when determining the level of access control, RBAC evaluates each scope and then applies the broadest one. This means that the user can access all objects to which the broadest scope applies even though the user may have a more restrictive scope for the same role through a different role assignment. This poses a potential problem for administrators who need to allow access control for a broad range of objects yet prevent access to more sensitive objects. For these objects, you can define exclusive scopes. Exclusive scopes use filters in the same way as regular scopes but unlike regular scopes, they deny access to objects included in the scope to anyone who is not part of the same or equivalent exclusive scope. Exchange Server 2010 allows you to control access to sensitive objects based on a customized scope that is designated as Exclusive at the time you create it. Users given a management role assignment with an exclusive scope are the only ones allowed to access the objects to which the scope filter applies. All other users are denied access, even if they have a role assignment with a regular scope filter that also applies to the objects.

You can use exclusive scopes to control access to recipient objects and Exchange Server objects. You can only use exclusive scopes with administrative or specialist roles, and not with end-user roles. Create exclusive scopes as you would any explicit scope. You can specify a recipient filter, a server filter, or a server list. Unlike regular scopes, which do not take effect until you assign a scope to a management role, the deny aspect of an exclusive scope takes effect immediately. This means that as soon as you create an exclusive scope, the objects contained within that scope are not accessible until you assign its management role. After assigning the role, the exclusive scope provides access to those assigned to the management role and scope. If an equivalent exclusive scope matches the same objects, the role assignees associated with that exclusive scope can still access the objects. Exclusive scopes control only the explicit recipient or configuration write scope of a role assignment. However, the implicit recipient or configuration read scope of the role assigned to a user or group still applies. This means that: Those assigned a role continue to see objects that match the roles implicit read scope. Those assigned other roles may be able to see objects contained within an exclusive scope if the read scopes of the other roles include the objects. However, the objects can only be modified by users who are assigned a role associated with the exclusive scope.

Managing Scopes

Use the following cmdlets to manage role scopes: Get-ManagementScope. View management scope information. New-ManagementScope. Define new management scopes. Set-ManagementScope. Modify management scopes. Remove-ManagementScope. Remove management scopes when they are no longer needed.

Get-ManagementScope
The syntax is:
Get-ManagementScope [-Identity <ManagementScopeIdParameter>] [-Orphan <SwitchParameter>] [-Exclusive <$true | $false>] [-Organization <OrganizationIdParameter>] [-DomainController <Fqdn>] [<CommonParameters>]

The Get-ManagementScope cmdlet allows you to gather and view information about management scopes based on different conditions. Using one or more parameters as input, you can retrieve management scopes based on the following criteria: A specific management scope by name. Management scopes with similar names. Management scopes that are no longer associated with a management role. Management scopes that enforce exclusive access.

A user must be granted access through role assignment before running this task. By default, role assignment grants the required access to the following role groups: Organization Management View-Only Organization Management Delegated Setup Hygiene Management

The parameters are:

Parameter Name Identity Description Specifies the name of the management scope. If the management scope name contains spaces, enclose the name in quotation marks. The Identity parameter accepts wildcard input values. Orphan Instructs the cmdlet to return a list of all management scopes not associated with a management role assignment. The Orphan parameter requires no input value. Exclusive When $true, instructs the cmdlet to return a list of all management scopes that are marked as exclusive. When $false, it returns only scopes that are not exclusive. Not available in on-premises installations.

Organization

Section 4 Review

Answer the questions listed on the slide above.

Section 5: Role Assignments and Role Assignment Policies

Introduction
This section describes how management role assignments work within the Exchange Server 2010 RBAC access control model. Additionally, this section provides an overview and discussion about how the RBAC elements work together to form the RBAC access model for Exchange Server 2010.

Objectives
After completing this section, you will be able to: Describe the function of role assignments and role assignment policies within the RBAC model. Use role assignments and role assignment policies.

What Are Role Assignment Policies?

Role assignment policies are configuration objects that link one or more user-level role assignments to a mailbox user. Each mailbox user object has a property called RoleAssignmentPolicy that designates the role assignment policy object that applies to the user. Each management role assignment that applies to the policy in turn applies to the associated mailbox user. This enables you to apply self-management roles to a large number of mailbox users by designating a role assignment policy at provisioning time. The rules governing the use of role assignment policies are: Multiple role assignment policies for a single organization are supported. Administrators can create and remove policies as required. One role assignment policy is the designated default policy for the organization and is automatically used at provisioning time unless you specify a different policy. You can designate any policy as the new default policy, as required. The process used to assign a management role to a role assignment policy is the same as that used to assign a role to a user or role group. A single-role assignment policy can link multiple role assignments to a mailbox user. Only one role assignment policy can apply to a user at a time. The policy applied to a mailbox user is managed using mailbox provisioning tasks. One or more users can be associated with a role assignment policy. The role assignments between role assignment policies and management roles have built-in scopes that restrict the scope of assignments to the users own mailbox or distribution groups.

The role assignment policy configuration objects are stored in AD DS under the CN=RBAC parent container in the CN=Policies sub-container.

Managing Role Assignments and Role Assignment Policies

Use the following cmdlets to manage role assignments: Get-ManagementRoleAssignment. View management role assignment information. New-ManagementRoleAssignment. Define new management role assignments. Set-ManagementRoleAssignment. Modify management role assignments. Remove-ManagementRoleAssignment. Remove management role assignments when they are no longer needed.

Use the following cmdlets to manage role assignment policies: Get-RoleAssignmentPolicy. View role assignment policy information. New-RoleAssignmentPolicy. Define new role assignment policies. Set-RoleAssignmentPolicy. Modify role assignment policies. Remove-RoleAssignmentPolicy. Remove role assignment policies when they are no longer needed.

Discussion: How Do the RBAC Elements Work Together?

Discuss the following key points about how the various RBAC elements work together to form the RBAC access control model for Exchange Server 2010. Role groups: One or more administrators can be members of a role group. They can also be members of more than one role group. The role group is assigned one or more role assignments. These link the role group with one or more administrative roles that define the tasks that can be performed. The role assignments can contain management scopes that define where the users of the role group can perform actions. The scopes determine where the users of the role group can modify configuration.

Role assignment policies: One or more users can be associated with a role assignment policy. The role assignment policy is assigned one or more role assignments. These link the role assignment policy with one or more end-user roles. The end-user roles define what the user can configure on his or her mailbox. The role assignments between role assignment policies and roles have built-in scopes that restrict the scope of assignments to the users own mailbox or distribution groups.

Direct role assignment: A role assignment can be created directly between a user or USG and one or more roles. The role defines the tasks that the user or USG can perform.

The role assignments can contain management scopes that define where the user or USG can perform actions. The scopes determine where the user or USG can modify configuration.

Test Case Scenario Using the RBAC Features

The following scenario describes an Exchange Server organization and how you can use the Exchange Server 2010 RBAC features to easily extend the desired level of access control.

Test Case Scenario

As administrator for Contoso, Ltd, you need to delegate Exchange Server recipient tasks to the Help Desk staff who are responsible for managing users in the Seattle and Dallas offices. Recipient tasks are used to manage mailbox users, mail users, and mail contacts. Only certain tasks should be available, depending on factors such as access to recipient objects and the expertise level of Help Desk engineers. Your goal is to use the new Exchange Server 2010 RBAC features to extend the minimum level of access control required with minimum complication. You must consider the personnel to whom you are granting access control. Help Desk personnel are divided into two groups: junior-level engineers with basic skills and senior-level engineers with advanced skills and specific areas of responsibilities. You can trust the junior-level personnel with all tasks that are nondestructive, whereas all other tasks are escalated to the senior-level engineers. Based on this model, you need two levels of access control: Tier 1 Help Desk personnel should have access to tasks for modifying existing recipient properties, but can neither mail-enable nor remove recipient objects. Tier 2 Help Desk personnel can mail-enable and mail-disable recipient objects, but cannot have access to other recipient tasks not directly related to their responsibilities. For example, tasks related to reconnecting a mailbox should not be available.

The corporate policy for managing the organization dictates that certain operations that mail-enable or mail-disable Active Directory objects must be restricted to the OU for which the administrator making the changes is responsible. Based on this policy, you must create further access control restrictions to limit access based on the OU of the recipient objects, as designated by the geographic location of the recipients: Tier 1 personnel can modify recipient properties of objects in both the Seattle and Dallas OUs. The vast majority of Help Desk requests are for changes to existing recipients. Therefore, it is more efficient for the tier 1 engineers to make these nondestructive, simple changes in either location. Tier 2 personnel should be restricted to managing users in one OU or the other, based on their areas of responsibility. There are certain Help Desk requests that require the enabling or disabling of recipient objects. These requests can only be handled by tier 2 engineers that have responsibility for a particular OU.

Test Case Solution

Based on the specifications, you decide to implement the following RBAC features:

You perform the following tasks: 1. Because tier 2 Help Desk personnel need access to only certain recipient tasks, a custom management role is required. Create a new custom management role called Tier2 HelpDesk from a copy of the default Mail Recipients role.
[PS] C:\>New-ManagementRole -Name Tier2 Helpdesk -Parent Mail Recipients

2. Identify the tasks to which tier 2 personnel should have access and then remove entries for all other tasks that are not required for the new custom management role.
[PS] C:\>Remove-ManagementRoleEntry -Identity Tier2 Helpdesk\ Connect-Mailbox

Now you must assign the new role to senior Help Desk personnel, but only so that they can use the new role to manage users in one OU or the other. This means two management role assignments are required, each scoped to a specific OU. As a best practice, assign the new role to role groups so that users added to the groups are automatically granted access control of the assigned roles. 3. Create two new role groups: Create a new role group called Dallas Tier2 HelpDesk, and assign role Tier2 HelpDesk with the effective scope of the Dallas OU.
[PS] C:\>New-RoleGroup -Name Dallas Tier2 HelpDesk -Roles Tier2 HelpDesk -RecipientOrganizationalUnitScope contoso.com/dallas

Next, create a new role group called Seattle Tier2 HelpDesk, and assign role Tier2 HelpDesk with the effective scope of the Seattle OU.
[PS] C:\>New-RoleGroup -Name Seattle Tier2 HelpDesk -Roles Tier2 HelpDesk -RecipientOrganizationalUnitScope contoso.com/seattle

As a result of these cmdlets, two management role assignments are created automatically. Their names are a composite of the names of the roles being assigned, plus the names of the role groups to which they were assigned. In this case, the role assignments are named Tier2 HelpDesk-Dallas Tier2 HelpDesk and Tier2 HelpDesk-Seattle Tier2 HelpDesk. Because tier 1 Help Desk personnel need access to only certain recipient tasks, you need another custom management role. You can base this custom management role on the first custom management role because it can inherit the required tasks, and it makes sense to create the tier 1 role as a child of the tier 2 role. To continue: 4. Create a new custom management role called Tier1 HelpDesk from a copy of custom management role Tier2 HelpDesk. You have identified the tasks to which tier 1 personnel should have access, and then removed as entries all other tasks not required on the new management role.

5. Assign the new role to junior Help Desk personnel so that they can use it to manage users in both OUs. You can accomplish this by using one role assignment because the Seattle and Dallas OUs are children of the domain root. Scopes that apply to a root apply to the children of that root as well. Create a new role group called Tier1 HelpDesk that assigns role Tier1 HelpDesk using the implicit scope of Organization. The result of this action creates a new management role assignment called Tier1 HelpDesk -Tier1 HelpDesk. 6. With these RBAC features in place, you can now add users as members of the USGs to extend access to the tasks made available by the assigned roles.

Section 5 Review

Answer the questions listed on the slide above.

Section 6: Troubleshooting RBAC

Introduction
This section introduces the diagnostic logging troubleshooting tool for Exchange Server 2010. It provides a general discussion about diagnostic logging that pertains to all the modules in this workshop. Additionally, it focuses on some troubleshooting tips and techniques for RBAC in particular.

Objectives
After completing this section, you will be able to: Troubleshoot RBAC. Describe and use diagnostic logging.

Troubleshooting RBAC

Most RBAC-related issues are similar to each other because you can pinpoint the issues as follows: User X cannot perform certain tasks, but should be able to do so. How do we find out why user X cannot perform these required tasks, and then how do we enable user X to perform the tasks? User X can perform certain tasks, but should not be able to do so. How do we find out why user X can perform these unauthorized tasks, and then how do we disable permissions for these tasks?

You can use the Get-ManagementRole -Cmdlet cmdlet to gather the required information about the task and the user

Example
Suppose user X can run the Set-Mailbox cmdlet. To understand how user X is able to run this cmdlet, start by determining which roles enable permissions to run this cmdlet, and then determine the roles that are assigned to user X that include the Set-Mailbox cmdlet. Specify the Get-ManagementRole cmdlet with the Cmdlet parameter to view a list of roles that include Set-Mailbox as a role entry. The syntax is:
Get-ManagementRole -Cmdlet Set-Mailbox

You can also use ExBPA reports to view the following errors and warnings:
Error Missing RBAC containers Missing precanned role types Missing precanned role groups Multiple default role assignment policies Warning No assignments to the role management role Empty Organization Management role group No default role assignment policies Role assignment policy without a MyBaseOptions role assignment Mailbox with no assignment (direct or indirect) to a MyBaseOptions role Exclusive scope with no role assignments

Diagnostic Logging

Modifying logging levels may help you troubleshoot issues that occur in an Exchange Server 2010 environment. You can use the Exchange Management Console or the Exchange Management Shell to configure your diagnostic logging levels.
Note: Changing the process logging level for a given process may not necessarily yield additional events in the event log. Many variables affect whether a change to the process logging level setting will increase the number of events. These variables include, but are not limited to, the actions being performed by the process and the number of events implemented in the source code for the logging level selected.

The logging level for each Exchange Server process determines which events are written to the Application event log in Event Viewer. You can configure the logging levels for any Exchange server roles in your organization. The default logging level is 0 (Lowest). We recommend that you return the logging level to the default setting after completing your troubleshooting activities.
Logging level Lowest Description Only critical events, error events, and events with a logging level of zero (0) are logged. Note: This is the default level for all services on Exchange servers. Low Medium High Expert Events with a logging level of 1 or lower are logged. Events with a logging level of 3 or lower are logged. Events with a logging level of 5 or lower are logged. Events with a logging level of 7 or lower are logged.

Events are divided into four categories: Informational. Information messages indicate state changes. Information messages do not require any action, but they can provide valuable data for monitoring the state of the Exchange Server over time. Warning. Warning messages indicate potential problems or issues that might require attention. Error. Error messages indicate an urgent condition that requires immediate attention. Critical. Critical messages indicate a serious error that has caused a failure of an Exchange Server component.

To modify the process logging level for an Exchange Server process, you must first determine whether the process is configurable. Events that are generated at different logging levels are specific to each Exchange Server process, and you must consider them carefully before changing diagnostic logging levels. This is to ensure that only events that are relevant to the issue under investigation are generated. For each Exchange Server process there are one or more categories that represent a component or operation of the process. The diagnostic logging level that is set on these individual categories determines the events that are generated for each process. After selecting the processes and categories in which you are interested, you next set the diagnostic logging levels for those processes. When Exchange Server generates an event that is less than or equal to the configured logging level, the event is logged. Typically, you set logging to the lowest level and only critical events are logged. However, when problems occur, increasing the process logging level can help generate events that capture information that you can use for detailed diagnostics. After changing a logging level for a given process, logging begins automatically at that level. To view current diagnostic logging levels, you must be assigned to the Exchange Servers or the View Only Configuration management roles. To change diagnostic logging levels, you must be assigned the Exchange Servers management role.

Using the Manage Diagnostic Logging Properties Wizard

To configure your logging level in the Exchange Management Console, do the following: 1. Start the Exchange Management Console. 2. In the console tree, navigate to Server Configuration, and then select the server upon which you want to enable logging. 3. In the Actions pane, click Manage Diagnostic Logging Properties.

4. In the Manage Diagnostic Logging Properties wizard, expand the component services for which you want to change the logging level, and then choose the applicable diagnostic logging level. 5. Click Configure.

Using the Exchange Management Shell

To configure your logging level for the applicable component services, specify the following cmdlet:
Set-EventLogLevel Identity <EventCategory> -Level <Lowest | Low | Medium | High | Expert>

Use the Get-EventLogLevel cmdlet to view the current logging level. Example 1 The following example returns the current logging level for the MSExchange Configuration Cmdlet* services:
Get-EventLogLevel -Identity "MSExchange Configuration Cmdlet*"

Example 2 The following example changes the MSExchange Configuration Cmdlet - Management Shell\RBAC logging level to High.
Set-EventLogLevel -Identity "MSExchange Configuration Cmdlet - Management Shell\RBAC" -Level High

Diagnostic Logging for RBAC

For RBAC specifically, the following component services generate RBAC event logs: MSExchange Configuration Cmdlet - Control Panel MSExchange Configuration Cmdlet - Management Console MSExchange Configuration Cmdlet - Management Shell MSExchange Configuration Cmdlet - Management Web Service MSExchange Configuration Cmdlet - Remote Management

There are two categories for each service: General: Events related to the operation of the management tasks RBAC: Events specific to RBAC processing

You must be granted access through role assignment before running these tasks. By default, role assignment grants the required access to the following role groups: Organization Management Server Management

Section 6 Review

Answer the questions listed on the slide above.

Lab 1A: Allowing a Group of Users to Create Distribution Lists

Lab 1B: Configuring and Testing RBAC

Module 1 Summary

This module described the RBAC access control model for Exchange Server 2010.