Securing MS Exchange 2010: Role Based Access Control (RBAC) Simplified

1. An introduction to the RBAC permissions model

Exchange 2010 introduces a brand new permissions model named “RBAC”, meaning Role Based Access Control. There’s plenty of documentation about RBAC since this is a new and important feature of Exchange 2010, but I did not find anything with simple and concise explanations that will help everybody understand how to manage permissions using RBAC at a glance.

Here’s a simple definition of RBAC:

RBAC enables grouping sets of actions (e.g. cmdlets, features from the graphical management console, as well as features from the Exchange Control Panel – the management console brought through an http connection) into different roles (e.g. a Mail Recipient creation role to manage Mailboxes, that is to create, modify or delete mail objects – mailboxes, mail-enabled users, mail-enabled contact, etc.).

Several roles can be combined into Management Groups where you can place Administrators or these roles can be directly assigned to end users using Management Role Policies.

2. Defining and using Role Groups: the RBAC permissions model for Administrators and Specialized Users

2.1 General Model

Management Role Entries are different sets of authorized actions called command-lets or functions with various parameters that are grouped into Management Roles. For example, Create-Mailbox and Delete-Mailbox are 2 command-lets included into the “Mail Recipient creation” role.

Note: You can also create your own roles! Imagine the possibilities as we have 599 Exchange commands in Powershell, each command with 5 to 15 parameters, for an average total of 6,000 parameters and tremendous possibilities of granularity!

That’s why Microsoft gave built-in Management Roles and Management Role groups that are more than enough to secure your Exchange Server 2010 infrastructure objects and configuration items.

Use Get-RoleGroup to list the available built-in Management Role groups.

Use Get-ManagementRole to list the available built-in Management Roles.

Use add-RoleGroupMember / remove-RoleGroupMember in powershell to add or remove Administrators names from the desired role group.

2.2 Example/Illustration

Here is a simple representation that will help you understand how Management Role Entries and Management Roles fit together:

First you have the authorized cmdlets called Management Role Entries:

These cmdlets are grouped into Management Roles

Management Roles are linked to Management Role Groups by Management role Assignments:

Figure: Graphical representation of the Role Group RBAC architecture

2.3 An important note on Role Assignments

Role Assignments are the links between Roles and Role Groups. These will always be identified in the form of “Management Role name – Management Role Group name” or “Management Role name – Management Role Group name - Delegating”, e.g. Mail Recipient Creation-Organization Management.

These also exist in the RBAC model to define the scope of actions. Scopes are defined in the Role Assigment level, either by a parameter of the New-ManagementRoleAssignment cmdlet (RecipientOrganizationalUnitScope) for OU Scopes, or by using the New/Set-ManagementScope for the Recipient and Configuration scopes.

The purpose of these is to limit the objects that an administrator can manipulate or to direct where administrators can perform their administration, and so these are split into 3 categories :

OU scope: introduced above, these are the simplest custom scopes, in which OU the group member can operate

Recipient scopes: the Exchange related AD objects a group member can manipulate

Configuration scopes: the servers and databases that group members can manipulate

There is one recipient scope and one configuration scope per Role Assignment.

Last important feature of the Management Role Assignment: the Exclusive Scope for explicit Management Scopes – these can limit the access to an AD object to these Role assignees only.

In the example illustration below, the “Recipient Administrators” in Ottawa can administer Bob, Peter and Kevin, but cannot administer David, Sharon, Henry, Jenny, Frank or Eric. The VIP Administrators can administer David, Sharon, Frank and Eric. The Executive Administrators can administer Henry, Jenny, Frank and Eric.

2.4 Management Role Assignment Policies, the “cousins” of management role groups

2.4.1 General model

Role Assignment Policies are different from Role Groups in the fact that these are only used at the user mailbox level. These are intended to enable end-users to manage their mailbox and distribution group configuration. Here is the Role Assignment Policy as defined by the Technet :

Mailbox are assigned a single role assignment policy, to which management roles (containing management role entries, as referred above) are linked by management role assignments.

2.4.2 Illustration

We notice some commonalities between Role Groups and Role Assignment Policies such as:

The management role entries (the authorized cmdlets or actions)

The management roles (defined by a set of cmdlets or actions – the management role entries)

The Management Role Assignments

Here’s the first difference: the scope of management role assignments for assignment policies are either

SELF : the role can read (if present in the recipient read scope) or modify (if present on the recipient write scope) only the properties of its current mailbox

or MYGAL : used with “Recipient Read Scopes” only - the role can view the properties of any recipient within the current user's global address list (GAL)

And as the Role groups were used for Exchange administration, the Management Role Assignment Policies are used for user rights assignments on their mailbox and distribution lists.

2.5 For your reference: the RBAC permissions model CommandLets

As introduced above,these are ALL the commandlets of powershell functions used to manage RBAC permissions components in Exchange Server 2010 SP1:

Manage Roles

Get-ManagementRole

New-ManagementRole

Remove-ManagementRole

Manage Role Assignments

Get-ManagementRoleAssignment

New-ManagementRoleAssignment

Remove-ManagementRoleAssignment

Set-ManagementRoleAssignment

Manage Role Entries

Add-ManagementRoleEntry

Get-ManagementRoleEntry

Remove-ManagementRoleEntry

Set-ManagementRoleEntry

Manage Scopes

Get-ManagementScope

New-ManagementScope

Remove-ManagementScope

Set-ManagementScope

Manage Role Assignment Policies

Get-RoleAssignmentPolicy

New-RoleAssignmentPolicy

Remove-RoleAssignmentPolicy

Set-RoleAssignmentPolicy

Manage Role Groups

Get-RoleGroup

New-RoleGroup

Remove-RoleGroup

Set-RoleGroup

Manage Role group members

Add-RoleGroupMember

Get-RoleGroupMember

Remove-RoleGroupMember

Update-RoleGroupMember

ADVICE : Use this table along with the PowerShell “Get-Help” cmdlet, and along with the above schemas to have a clear view of what you are doing and what you want to do to secure your Exchange Server 2010 infrastructure!

2.5.1 Common actions we then can do using the Exchange Management Shell, the Exchange Control Panel, or the Exchange Management Console

Here’s a list of commands, given as examples to apply the above concepts in your environment, all taken from various places on TechNet and tested on a test lab environment:

“Defaulting” a custom Management Role AssignmentPolicy for newly created mailboxes:

General:

Set-RoleAssignmentPolicy <assignment policy name> -IsDefault

Real life :

Set-RoleAssignmentPolicy “Limited Mailbox Configuration” -IsDefault

List all users that are granted the permissions provided by a specific management role :

Get-ManagementRoleAssignment -Role <role name> -GetEffectiveUsers

2.5.2 SAVING The best for LAST: Manage your RBAC groups with the Exchange Control PaneL (ECP)

The reason why I put this section at the end is that some RBAC management features are only available by using PowerShell. Understanding the RBAC schema and the associated PowerShell functions will help you manage every aspect of your Exchange Server 2010 security.

Also, there are many things you cannot do in the ECP, so you will need to use the Exchange Management Shell (PowerShell with the Exchange extensions). The only RBAC management tasks you can do in ECP are modifying the memberships of role groups and adding or removing roles from role assignment policies.

You must use the Exchange Management Shell to manage every other aspects of RBAC, such as:

Create, delete or modify custom roles

Create or delete Role Groups

Assign roles to Role Groups

Modify the scope or Role Assignment

Assign a role directly to a user account

So here are screenshots of ECP regarding RBAC management:

Use the Exchange Management console to access the ECP RBAC editor:

You can see the built-in management roles with the assigned roles (these will all use the default scopes) :

Example of the Organization Management role group configuration in the ECP:

3. Conclusion

With Exchange Server 2010, permission management is much clearer, granular, and manageable. You can always have a clear view of who has the access to what and where.

The Get-ManagementRoleAssignment commandlet is a good monitoring PowerShell command with which you can audit your permissions assigned to administrators.

Note: to audit all users and groups in your organization to understand their effective permissions, you can use PowerShell piping, like Get-ManagementRole | Get-ManagementRoleAssignment.

Finally, use the Exchange Management Shell to administer and manage your Exchange Server 2010 permissions using the RBAC functions, and the Exchange Control Panel once you understand the concepts of the RBAC model and the ECP RBAC management limitations.

Very useful information , I like this post. I’m agreed on each point you’ve discussed ,these are major problems of students these days. Many of us can’t take regular classes due to financial or other reasons, it is the best opportunity for them. Thanks
for sharing this nice post.