Mod 01 e2010 Aot Sp1 Rbac Workbook

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, e-

mail 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.


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 object’s

properties, or an individual property of an object. There are two types of access control

lists maintained within an object’s 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

object’s 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 object’s 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 Move-

Mailbox 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.


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 user’s request.

If RBAC allows an action to proceed, the action is performed in the context of the

Exchange Trusted Subsystem and not the user’s 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 client’s 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 company’s 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 role’s

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


• 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 Description

Active Directory Permissions

Enables administrators to configure Active Directory permissions.

Address Lists Enables administrators to manage address lists, global address list (GALs), and offline address lists.

Audit Logs Enables administrators to manage audit logs.

Cmdlet Extension Agents Enables administrators to manage cmdlet extension agents.

Database Availability Groups

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.

Database Copies Enables administrators to manage database copies on individual servers.

Databases Enables administrators to create, manage, mount, and dismount mailbox and public folder databases on individual servers.

Disaster Recovery Enables administrators to restore mailboxes and DAGs.

Distribution Groups Enables administrators to create and manage distribution groups and distribution group members.

Edge Subscriptions Enables administrators to manage edge synchronization and subscription configuration between Edge Transport servers and Hub Transport servers.

E-Mail Address Policies Enables administrators to manage email address policies.


Exchange Connectors 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.

Exchange Server Certificates

Enables administrators to create, import, export, and manage Exchange Server certificates on individual servers.

Exchange Servers Enables administrators to manage Exchange Server configuration on individual 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 Enables administrators to manage cross-forest and cross-organization sharing.

Information Rights Management

Enables administrators to manage the Information Rights Management features of Exchange Server.

Journaling Enables administrators to manage journaling configuration.

Legal Hold Enables administrators to configure whether data within a mailbox should be retained for litigation purposes.

Mailbox Import Export Enables administrators to export information from, and import information to, mailboxes.

Mailbox Search 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 mail-enable 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


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 Enables administrators to manage MailTips.

Message Tracking Enables administrators to track messages.

Migration Enables administrators to migrate mailboxes and mailbox content into or out of a server.

Monitoring 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.

Move Mailboxes Enables administrators to move mailboxes between servers in an organization, and between servers in different organizations.

Organization Client Access Enables administrators to manage Client Access server settings.

Organization Configuration 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.

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) configuration─such as authentication and connection settings─on individual servers.


Public Folder Replication Enables administrators to start and stop public folder replication.

Public Folders 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 Enables administrators to manage transport Receive connector configuration, such as size limits on an individual server.

Recipient Policies Enables administrators to manage recipient policies such as provisioning policies.

Remote and Accepted Domains

Enables administrators to manage remote and accepted domains.

Retention Management Enables administrators to manage retention policies.

Role Management 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 Enables administrators to manage transport Send connectors.

Support Diagnostics 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 Enables administrators to manage transport agents.

Transport Hygiene Enables administrators to manage antivirus and anti-spam features.

Transport Queues Enables administrators to manage transport queues on an individual server.

Transport Rules Enables administrators to manage transport rules.

UM Mailboxes Enables administrators to manage the Unified Messaging configuration of mailboxes and other recipients.

UM Prompts Enables administrators to create and manage custom Unified Messaging voice prompts.

Unified Messaging Enables administrators to manage Unified Messaging servers.

This role does not enable you to manage Unified Messaging-specific mailbox configuration or Unified Messaging prompts. To manage Unified Messaging-specific mailbox configuration, use the UM Mailboxes role. To manage Unified Messaging prompts, use


the UM Prompts role.

UnScoped Role Management

Enables administrators to create and manage unscoped top-level management roles in an organization.

User Options 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.

View Only Configuration 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 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 self-

management 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.


MyBaseOptions Enables users to view and modify the basic configuration of their mailboxes and associated mailbox settings.

MyContactInformation Enables users to modify their contact information. This information includes their addresses and phone numbers.

MyDiagnostics Enables users to view the calendar diagnostic log for their mailbox calendars.

MyDistributionGroupMembership Enables users to view and modify their memberships in distribution groups in an organization, provided that these distribution groups allow manipulation of group membership.

MyDistributionGroups Enables users to create, modify, and view distribution groups and modify, view, remove, and add members to distribution groups that they own.

MyProfileInformation Enables users to modify their names.

MyRetentionPolicies Enables users to view their retention tags, and to view and modify their retention tag settings and defaults.


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

MyVoiceMail 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[]>]




Get-ManagementRole -Identity <RoleIdParameter>

-Recurse <SwitchParameter>





Get-ManagementRole -Identity <RoleIdParameter>

-GetChildren <SwitchParameter>





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 Description

Identity 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 Returns a list of all management roles that include the specified script name.

ScriptParameters 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,


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


Section 3: Management Role Groups

Introduction

This section describes how management role groups work within the Exchange Server

2010 RBAC access control model.

Objectives


• 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 mailbox-

enabled 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 Description

Delegated Setup Allows administrators to deploy previously provisioned 2010 Exchange servers.

Discovery Management

Allows administrators and users to perform mailbox searches for data that meets specific criteria.

Help Desk Allows users to perform limited recipient management of Exchange Server 2010 recipients.

Hygiene Management

Allows administrators to configure Exchange Server 2010 antivirus and anti-spam 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.

Organization Management

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.

Public Folder Management

Allows administrators to manage public folders and databases on 2010 Exchange servers.

Recipient Management

Allows administrators to have administrative access to create or modify Exchange Server 2010 recipients.

Records Management

Allows users to configure compliance features, such as retention policy tags, message classifications, and transport rules.

Server Allows administrators to have administrative access to the Exchange Server

Role Group Description

Management 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 tools−such as

ADSIEdit−that 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 group−which contains its own members−to 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 built-

in 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


Section 4: Management Role Scopes

Introduction

This section describes how management role scopes work within the Exchange Server

2010 RBAC access control model.

Objectives


• 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 user’s 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 user’s 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 role’s 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>]




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



• View-Only Organization Management

• Delegated Setup

• Hygiene Management

The parameters are:


Identity 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.

Organization Not available in on-premises installations.

Section 4 Review


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


• 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 user’s 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 user’s 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


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


• 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 Warning

Missing RBAC containers No assignments to the role management role

Missing precanned role types Empty Organization Management role group

Missing precanned role groups No default role assignment policies

Multiple 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 Description

Lowest 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 Events with a logging level of 1 or lower are logged.

Medium Events with a logging level of 3 or lower are logged.

High Events with a logging level of 5 or lower are logged.

Expert 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



• Server Management

Section 6 Review


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.

Documents

Mod 01 e2010 Aot Sp1 Rbac Workbook