Exchange Server 2010 Introduction To Supporting Administration
Exchange Server 2010 Introduction To Supporting Administration
Exchange Server 2010 Introduction To Supporting Administration
Supporting Administration
Role Based Access Control
Jonathan Runyon
Exchange 2010 Content BRE
Microsoft
1 1/1/2009 Microsoft Confidential - For Internal Use Only
1
Module Overview
Before You Begin
Before starting this module you should:
Be familiar with using Microsoft Windows Active Directory
permissions to control administrative access to objects associated
with Windows based applications.
Be familiar with using Windows PowerShell commands to manage
an Exchange organization.
What You Will Learn
Describe how Role Based Access Control is used to manage access
to administrative tasks and control their degree of functionality in
an Exchange 2010 environment.
Apply Role Based Access Control in a variety of administrative
scenarios.
Troubleshoot the implementation of Role Based Access Control
using diagnostic tools and investigative methods.
3
Terminology
Term Definition
ACL Access control list - A list of security protections that applies to an object. (An object can be a file,
process, or anything else having a security descriptor.)
Administrator A person employed to maintain and operate a computer system and/or network. Administrators are
usually charged with installing, supporting, and maintaining servers or other computer systems, and
planning for and responding to service outages and other problems. For the purposes of this
module an administrator is an IT Pro whose primary responsibility is to manage an Exchange
organization.
Authentication The process for verifying that a user, computer, service, or process is who or what it claims to be.
Authorization The act of controlling access and rights to a resource. For example, allowing members of one group
to read a file, but allowing only members of another group to alter the file.
Credentials Previously authenticated logon data that a security principal uses to establish its own identity, such
as a password, or a Kerberos protocol ticket. Credentials are used to control access to resources.
Delegation The transfer of administrative responsibility for a specific administrative task from a higher authority
to a lower authority. Delegation of administration involves a higher-level administrator granting a
controlled set of permissions to a lower-level administrator in order to carry out a specific
administrative task.
digital identity The unique identifier and descriptive attributes of a person, group, computer, device or service.
Group A collection or association of user accounts (identities) and/or other groups.
IT Pro Information Technology Professional – a person responsible for the technical evaluation,
deployment, maintenance and support of software and hardware in a business.
identity store A repository in the form of a directory that contains digital identities. Active Directory provides an
identity store with a well-defined schema for what information can be stored and in what form it
can be recorded.
least privilege The principle that every element in a computing environment (such as a process, a user or a program) must be
able to access only information and resources necessary to its rightful function.
4
Terminology (continued)
Term Definition
privilege The right of a user to perform various system-related operations, such as shutting down the
system, loading device drivers, or changing the system time. A user's access token contains a list of
the privileges that the user or the user's groups hold.
role An abstraction that represents a set of functional responsibilities; a role can be comprised of
specific permissions needed to discharge those responsibilities.
RBAC Role based access control — An access-control mechanism based upon assigning users or
processes to roles.
scope A collection of objects or resources with a distinct authorization policy. A scope can represent a
physical collection, such as a folder, or a more flexible collection of resources, such as *.doc.
Applications can use the scope as necessary to group resources, and must be able to map the
requested resource to its scope at the time the application checks the access for a user.
security context The security attributes or rules that are currently in effect. For example, the current user logged on
to the computer or the personal identification number entered by the smart card user.
task One or more low-level operations. The purpose of a task is to determine which low-level
operations are required to do some unit of work that is meaningful to administrators. An example
of a task is cmdlet Set-Mailbox.
token (access token) An access token contains the security information for a logon session. The system creates an
access token when a user logs on, and every process executed on behalf of the user has a copy of
the token. The token identifies the user, the user's groups, and the user's privileges. The system
uses the token to control access to securable objects and to control the ability of the user to
perform various system-related operations on the local computer.
top level A top level administrator has access to all resources and operations associated with an application
administrator or system. and controls access
user An end user. In order to identify themselves for the purposes of accounting, security, logging and
resource management, a user has an account (a user account) a username, and a password. A user
account allows one to authenticate to system services. For the purposes of this module, a user has
a mailbox used for messaging and collaboration but generally is not involved directly in Exchange
administration.
6
Scenarios
Organization Management
Server Management
Database Management
Recipient Management
Records Management
Self-Serve Management
Specialist Management
9
Exchange 2003
The following roles were applied to users and groups
through the Delegation Wizard in Exchange System
Manager:
Exchange Full Administrator
Exchange Administrator
Exchange View Only Administrator
10
Exchange 2007
The following roles are applied to users and groups using
the Exchange Management Console and the Exchange
Management Shell:
Exchange Organization Administrators
Exchange Recipient Administrators
Exchange View-Only Administrators
Exchange Public Folder Administrators
Exchange Server Administrators
11
Challenges
Current management role implementation is limited
Access control management is complex
Permissions are focused on objects and not tasks
Excessive privileges required for some Exchange
operations
Object access auditing and delegated permissions
reporting is difficult
There is no support for Self-Service management
15
RBAC Basics
ACLs and Exchange Administrative Applications
Leveraging Role Based Access Control
Authorization Manager Model
19
Components
Management Roles
Management Role Entries
Built-In Management Roles
Management Role Scopes
Role Groups
Role Assignment Policies
Management Role Assignments
Exchange Default USG Implementation
23
User, USG,
Policy
“Who”
Role
Assignment
Role Scope
“What” “Where”
24
Management Roles
Built-In Management Roles
Custom Management Roles
Management Role Entries
Unscoped Top Level Management Roles
26
Mail Recipients
│
└─Tier2 HelpDesk
│
└─Tier1 HelpDesk
25
ApplicationImpersonation This role enables the user to configure whether an application is able to
impersonate a mailbox. Impersonation enables the sending account to
send as the specified user rather than on behalf of the specified user.
33
Implicit Scopes
Implicit scopes are the default scopes that apply to a
management role type
An implicit scope applies to a parent built-in role, and all custom
roles based on that role
By default all roles have four implicit scopes:
RecipientReadScope – what recipients can the assignee “see”?
RecipientWriteScope – what recipients can the assignee modify?
ConfigReadScope – what configuration objects can the assignee
“see”?
ConfigWriteScope – what configuration objects can the assignee
modify?
35
Custom Scopes
Use custom scopes when implicit scopes and relative
scopes do not provide the level of control required
Defined and stored as configuration objects in AD, or
applied by filter at time of assignment
Override either implicit recipient write scope or implicit
configuration write scope
Scope definition uses filter (OPath) to determine scope
boundary
Recipient filterable attributes
Example: department, office, manager
Exchange server filterable attributes, or server list
Example: AD site, server role
38
Exclusive Scopes
Scopes may overlap when RBAC evaluates access control
A given role assignee may have access to sensitive objects
that fall within a broad scope
Administrators may need to extend access control for
broad range of objects, but prevent access to more
sensitive objects to which exclusive access must be
maintained
Exclusive scopes deny access to objects included in the
scope to only the role assignee where the scope is used in
a role assignment
Exclusive scope scenario:
39
Role Groups
Special Universal Security Groups (USG) that simplify role
assignment to a group of users
Members of the role group have access control provided by the
roles assigned to the group, as if the roles had been assigned
directly to the members
Managed using Exchange management tasks so that there
is no need to have access to AD management tools
Possible to create a role group, assign roles and add
members to the group in one command
45
Preventing Lockout
A lockout occurs when an administrator makes so many
changes to access control settings that they are no longer
able to manage access control
Administrators can make changes to certain built-in access
control components, but never to the point where a
complete lockout would occur
The level of access control required to manage RBAC is
always preserved
What? Who?
RoleGroup
or USG
Role
Role
Assignment
Policy
Review
Role Individual
Entry
Role
Entry
Role Role Assignment
Entry
Role
Entry
Role
Entry Recipient Write Scope Recipient Read Scope
Role
Entry
Configuration Write Scope Configuration Read Scope
Where?
53
Implementation
Authorization Model
RBAC/Management Tool Interaction
61
Authorization Model
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 those users that
already have high level administrative access.
RBAC relies on PowerShell version 2.0 and WinRM to
provide remote PowerShell through IIS
RBAC authorization code is incorporated into this implementation
All Exchange 2010 management tools connect through IIS
Remote PowerShell provides a server side runspace where
commands execute
This is where RBAC executes access control
62
Split Permissions
Split permissions is the separation of Exchange
management and Active Directory management.
Split permissions typically make a distinction between the
creation of security principals in Active Directory, such as
users and security groups, and the subsequent
configuration of those objects.
Exchange 2010 lets you choose between a shared
permissions model and a split permissions model.
Exchange 2010 defaults to a shared permissions model.
67
Shared Permissions
The shared permissions model allows Exchange
administrators using the Exchange management tools to
create security principals in Active Directory
These roles enable the creation of security principals:
Managing Roles
Watch This: Role Management
Managing Roles using Exchange PowerShell commands
68
Get-ManagementRoleEntry
Add-ManagementRoleEntry
Set-ManagementRoleEntry
Remove-ManagementRoleEntry
83
Get-ManagementScope
New-ManagementScope
Set-ManagementScope
Remove-ManagementScope
104
Get-RoleGroup
New-RoleGroup
Set-RoleGroup
Remove-RoleGroup
Get-RoleGroupMember
Add-RoleGroupMember
Update-RoleGroupMember
Remove-RoleGroupMember
119
Get-ManagementRoleAssignment
New-ManagementRoleAssignment
Set-ManagementRoleAssignment
Remove-ManagementRoleAssignment
148
Get-RoleAssignmentPolicy
New-RoleAssignmentPolicy
Set-RoleAssignmentPolicy
Remove-RoleAssignmentPolicy
174
RBAC Reporting
Most issues can be described in simple terms
Because there are many layers to RBAC, it is important to
gather the right information
If you know the task and user, you can gather the required
information
Use Get-ManagementRole with –Cmdlet to see a list of
roles
194
Specialized Scripts
Exchange Management Shell makes it possible to create
powerful scripts for gathering diagnostic information
useful to troubleshooting RBAC issues.
Three sample scripts are included with this module to
demonstrate how these tools would be used.
Find-Assignee.ps1 - used to find users and group that have access
to the cmdlet and cmdlet parameter specified.
Compare-Roles.ps1 - used to compare the cmdlets made available
by two different management roles, generating a list of cmdlets
that are common to both roles, and a list of cmdlets that are
exclusive to each role.
Gather-RBACData.ps1 - used to gather a comprehensive report of
RBAC information for the user or group specified.
194
Appendix
RBAC Application Log Events
RBAC Performance Counters
Questions
This training package content is proprietary and confidential, and is intended only for users described in the training materials. Content and
information designated for limited distribution is provided to you under a Non-Disclosure Agreement and cannot be distributed. Copying or
disclosing all or any portion of the content and/or information included in such packages is strictly prohibited.
The contents of this package are for informational and training purposes only and are provided "as is" without warranty of any kind, whether
express or implied, including but not limited to the implied warranties of merchantability, fitness for a particular purpose, and non-
infringement.
Training package content, including URLs and other Internet Web site references, is subject to change without notice. Because Microsoft
must respond to changing market conditions, the content should not be interpreted to be a commitment on the part of Microsoft, and
Microsoft cannot guarantee the accuracy of any information presented after the date of publication. Unless otherwise noted, the 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.
Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this
document. Except as expressly provided in 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.
Complying with all applicable copyright laws is the responsibility of the user. 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.
For more information, see “Use of Microsoft Copyrighted Content “at http://www.microsoft.com/about/legal/permissions/.
Microsoft®, Internet Explorer, and Windows® are either registered trademarks or trademarks of Microsoft Corporation in the United States
and/or other countries. Microsoft products mentioned herein may be either registered trademarks or trademarks of Microsoft Corporation in
the United States and/or other countries. All other trademarks are property of their respective owners.