What’s this RBAC in Exchange Server 2010 anyway? – Part 1
2010-03-30 2 Comments
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!
