What’s this RBAC in Exchange Server 2010 anyway? – Part 1

This is part one in my series of posts about Role Based Access Control. If you find an error of any sort, have any questions or thoughts about it please do not hesitate to drop a comment or contact me.

Role Based Access Control is the new way of handling user rights in Exchange Server 2010. Before RBAC you had to work with ACL and it could be quite tricky and hard to troubleshoot. With RBAC you can set wide or very specific rights for both administrators and end-users, enabling you to have more detailed control. You can set both administrative rights in Exchange server 2010 and you can give users the right to administer their own mailbox and distribution groups. First, let´s just take a look on the different components that RBAC consists off:

Component Explanation
Role holder Mailbox that is assigned to a role group
Management role group Universal security group for managing Exchange Server permissions
Management role Container for grouping other RBAC components
Management role entry Defines which Exchange Server cmdlets an administrator can run
Management role assignment Links the management role group to a management role
Management role scope Defines where the administrator can perform the tasks

There are two primary ways of assigning permissions to users, management role groups and management role assignment policies. We will start by looking at Management Roles, Management Role Entries and Management Role Types, they are fundamental to groups and policies.

Management Roles

Management roles is a way to logically group a number of cmdlets which makes it easier to identify the specific roles an administrator or user should have access to. One role can provide access to view or modify the configuration of Exchange 2010 components. For example mailboxes, transport rules, ActiveSync policies and recipients. These roles can be grouped together in to management role groups and management role assignment policies. We will look more at these two further on. Management roles can be assigned to role groups, role assignment policies and directly to users. The latter is not recommended though, assigning roles directly to users will most likely make you environment unnecessarily complex to administrate.

NOTE: End-user management roles can only be added to role assignment policies, not management role groups.

Built-in management roles

There is a large number of pre-made built-in management roles that will be enough for most scenarios and covers a lot of different areas of Exchange Server 2010. These roles can’t be changed or altered in anyway. You can however create your own management roles and include the built-in ones. A new management role can be changed but that is an advance procedure and not recommended. I will not cover that topic in this post but might add it later.

There are a large number of built-in management groups, here are some examples:

  • Mail Recipient Creation Role – Enables the right to create mailboxes, mail users, mail contacts, distribution groups, and dynamic distribution groups
  • Move Mailboxes Role – enables administrators to move mailboxes between servers
  • Databases Role – enables the right to create, manage, mount, and dismount mailbox and public folder databases

A complete list of roles can be found here: http://technet.microsoft.com/en-us/library/dd638077(printer).aspx

Management Role Types

Management Role types defines the scope for management roles. It is divided into 3 different categories:

  • Administrative or specialist – Has a broad impact in the Exchange organization, Roles of this role type enable tasks such as server or recipient management, organization configuration, compliance administration, and auditing.
  • User-focused – User specific scope, enables user oriented tasks such as user profile configuration, self-management and management of user-owned distribution groups.
  • This type enables tasks such as application impersonation and the use of non-Exchange cmdlets or scripts.

There are numerous types to choose from, a couple of examples follow:

  • Databases – This role type is associated with roles that enable administrators to create, manage, mount, and dismount mailbox and public folder databases on individual servers. This type affects specific servers.
  • MailTips – Associated with roles that enable administrators to manage mailtips, affects the entire Exchange organization.

Unscoped Top Level Management Roles

With the use of Unscoped Top Level Management Roles you can control access to custom scripts and non-Exchange cmdlets for users. Since these rules have no parents that defines its content it is called Top Level and considered equal to built-in management roles. Unscoped roles always enable the user to do organization wide configurations. Granting a user this access will give him or her access to any object in the Exchange Server 2010 organization. These roles should be used with caution but they can be very useful. For example, you can create a script and include it in a role. When you assign that role to a user, he or she will be able to perform only the specific functions provided by the script.

Create an Unscoped Role

To create a new Unscoped Role:
New-ManagementRole <name of new role> –UnscopedTopLevel

Management Role Entries

Entries are the basic part of a Management Role. It is included in every role, without entries there would be no roles. An entry can be a cmdlet, permission or a script that you want to include in a role. Entries can be added or removed depending on what type of role you are editing. To add a script you need to use the previously mentioned Custom Management Role.

View Role Entries

To view a list of role entries on a specific role:
Get-ManagementRoleEntry <role name>\*

If you want to view the details of a single role entry:
Get-ManagementRoleEntry <role name>\<cmdlet name> | FL

There are plenty of more variations of the Get-ManagementRoleEntry command and information on this can be found here: http://technet.microsoft.com/en-us/library/dd351179.aspx

Add a Role Entry to a Role

To add entries to a role use this command:
Add-ManagementRoleEntry <child role name>\<cmdlet>

Again, there is more information that can be found here: http://technet.microsoft.com/en-us/library/dd335180.aspx

Change a Role Entry

To add parameters to a role entry use this command:
Set-ManagementRoleEntry <role name>\<cmdlet> -Parameters <parameter 1>, <parameter 2>, <parameter…> -AddParameter

To remove parameters from a role entry:
Copy Code Set-ManagementRoleEntry <role name>\<cmdlet> -Parameters <parameter 1>, <parameter 2>, <parameter…> -RemoveParameter

More information here: http://technet.microsoft.com/en-us/library/dd298005.aspx

Remove a Role Entry from a Role

You can of course remove an management role entry from a role:
Remove-ManagementRoleEntry <management role>\<management role entry>

And there is of course more information to this as well: http://technet.microsoft.com/en-us/library/dd297947.aspx

Custom Management Roles

When the built-in management roles aren’t enough you can create and configure custom management roles. These are based on built-in management roles and inherit all parent entries. You can change a custom management role to match your specific needs by removing inherited entries. Note that you can only use inherited entries. You cannot add other specific entries to a custom management role. I would not recommend the use of custom management roles unless it is absolutely necessary, they are quite complex. Built-in management roles will be enough for most scenarios.

Create a Custom Management Role Management Role Entry

Entries are the basic part of a Management Role. It is included in every role, without entries there would be no roles. An entry can be a cmdlet, permission or a script that you want to include in a role. Entries can be added or removed depending on what type of role you are editing. To add a script you need to use the previously mentioned Custom Management Role.

Unscoped Top Level Role Entries

When used with a Custom Management Role, an entry is called Unscoped Top Level Role Entry. There are a couple of things to consider when creating these entries.

  • All parameters for the entries needs to be specified, Exchange will try to verify these. Only specified Parameters will be available to the users.
  • Remember to update the role manually if you change any of the entries. Exchange does not update the role.
  • All scripts must be placed in the Exchange 2010 scripts directory (Default: C:\Program Files\Microsoft\Exchange Server\V14\Scripts).
  • Remember to install all Non-Exchange cmdlets on all servers. Also remember to add the Windows PowerShell snap-in name for the cmdlet.

Management Roles Summary

Management roles can be divided in a number of different parts:

  • Built-in Management Roles – represents a number of predefined roles that cannot be changed. Will cover most needs
  • Unscoped Top Level Management Roles – Controls access to custom scripts, permissions and non-exchange cmdlets, always organization wide.
  • Custom Management Roles – Based on Built-in Management Roles, inherited entries can be removed.

We also have two types of entries:

  • Management Role Entries – Included in every role, can be a cmdlet, permission or a script.
  • Unscoped Top Level Role Entry – Define all parameters, manual role update after changes.

Last but not least:

  • Management Role Types – Defines the affecting scope for management roles, three descriptive categories.

In my next post I will continue with Scopes, Management Role Groups and Management Role assignment Policies, thanks for reading!

Part 1 in this series can be found here!

Part 2 in this series can be found here!

Part 3 in this series can be found here!

Advertisements

2 Responses to What’s this RBAC in Exchange Server 2010 anyway? – Part 1

  1. Pingback: What’s this RBAC in Exchange Server 2010 anyway? – Part 2 « Martin's Wonderful World of Unified Communications

  2. Pingback: What’s this RBAC in Exchange Server 2010 anyway? – Part 3 « Martin's Wonderful World of Unified Communications

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: