Role Based Access Control (RBAC) is the new permission model introduced in Exchange 2010. Using RBAC we grant administrators the required permissions only and we do this using Exchange commands rather than Access Control Lists (ACLs).
RBAC answers the "who is allowed to do what, and where is he allowed to do this". To simplify, assume you want an administrator to be only able to modify the phone number attribute of the employees in a specific department; RBAC enables you to do just that.
The RBAC model is based on Role Groups consisting of:
(Who) - Management Role Group: Universal Security Groups (USG) used to assign tasks to a group of role holders. These are the users performing the tasks.
(What) -Management role and management role entries: define the tasks and permissions that are assigned to users.
(Where) -Management role scope: where the tasks can be run i.e. organizational unit, group of users or other specific objects.
Management role assignment: links the tasks to groups.
There are different types of role groups:
Built-in role groups: the role groups included by default in Exchange 2010.
Linked role groups: used if Exchange 2010 is installed in a resource forest and the users are in a separate forest (a trusted foreign forest). It links role groups in the resource (Exchange) forest to a USG in the trusted foreign forest. Each linked role group is assigned to only one USG in the trusted foreign forest.
For the management roles, there are a Built-in, Custom and Unscoped Top Level management roles. If the built-in management roles (group of related tasks and cmdlets) do not meet our requirements, we can combine multiple roles to create a new custom (child) management role. For example, if you want to give a specialist user the ability to manage e-mail address policies and journal rules in your organization, you can assign the built-in E-Mail Address Policies and Journaling roles to a role group.
The child custom management role, only contains the management entries (cmdlets) that exist in the built-in parent management roles.
An Unscoped Top Level management role is an organization wide management role. Anyone assigned an unscoped top level role will be able to modify any object in the organization. This is used to allow users to run custom scripts or non-Exchange cmdlets on an Exchange server. The role cannot contain Exchange cmdlet entries, but the cmdlets can be added to the script which is itself an entry of this management role. For more information on unscoped top level management roles, see http://technet.microsoft.com/en-us/library/dd298116.aspx#unscoped.
To limit the access rights of specialist users or administrators to a specific scope, we apply a management scope to the role. There are two types of scopes:
Regular scope: defines where users have access.
Exclusive scope: same as regular scopes but with the difference that using exclusive scope you can deny access to objects within it, if no role assignment is associated with this scope.
To explain the difference between regular and exclusive scopes let's see the following example:
In the Sales OU we have the "Sales Regular Scope" and the exclusive "Sales VIP Scope". Sales Administrators are responsible to perform some task on all users within the Sales OU except for the VIPs. To accomplish this, we create an exclusive scope that includes the VIP users. Now the Sales Manager recipient object cannot be controlled by the commands in the Sales Regular Scope because it is included in the exclusive scope. To allow access and control on the objects within the exclusive scope, a role assignment would have to be created in order to link the scope to a management role.
To assign management roles and grant users the required permissions, Microsoft recommends using management role assignment policies. Roles are added to a role assignment policy, if needed you then change the policy. Otherwise the role is added to a role group and set the membership as needed.
Configuring and testing RBAC
Now that we have summarized Role Based Access Control and its components in Exchange server 2010, we will start testing it.
We will test the following scenario:
We have a Sales OU that contains the employees in the sales department (Sales1 and Sales2). We have the user "Sales Admin1" who will be responsible for editing the following information about users in the Sales OU:
- Mobile phone number
- Office information
- CustomAttribute1, this attribute is often used in some cmdlets for filtering; for example a filter to test dynamic distribution group membership
1- Creating the Management Scope (Where)
Firstly we will create the scope within which the role group members may run commands. To create a ManagementScope run the command:
New-ManagementScope -Name "Scope-Sales OU" -RecipientRoot "Contoso/Sales" -RecipientRestrictionFilter {RecipientType -eq "UserMailbox"}
The RecipientRoot parameter identifies the OU that contain the recipient objects. These will be filtered based on the RecipientRestrictionFilter parameter. The recipient objects within this OU matching the filter, are included in the scope.
We can see the full details for the scope using the cmdlet
Get-ManagementScope -Identity "Scope-Sales OU" | FL
2- Creating the Management Role (What)
Next step we will create a Management Role which defines the tasks that the specialist user or delegated administrator can do.
New-ManagementRole -Name "MR-Sales Admins" -Parent "Mail Recipients"
The command above will create a child custom management role with the "Mail Recipients" built-in management role as its parent. We don't want the members of the role group to have the ability to run all the commands available in the parent management role so we will remove all the cmdlets (management role entries) from the custom role that we have just created and then add the required cmdlets with the required parameters only.
To remove the management role entries run the command:
Get-ManagementRoleEntry "MR-Sales Admins\*" | where {$_.name -ne "Get-Mailbox"} | Remove-ManagementRoleEntry
We removed all cmdlets except for one (Get-Mailbox) because the management role should always contain at least one cmdlet. Apart for that it does make sense to grant the admin access to this cmdlet in this case. To check which cmdlets are now available in this management role use the command:
Get-ManagementRoleEntry "MR-Sales Admins\*"
Now we will add the required cmdlets together with the parameters we want to allow.
Add-ManagementRoleEntry "MR-Sales Admins\Set-User" -Parameters Identity, MobilePhone, Office
Add-ManagementRoleEntry "MR-Sales Admins\Set-Mailbox" -Parameters Identity, CustomAttribute1
3- Creating the Role Group (Who)
After defining the management scope and creating the management role, now we will create the role group whose members will have the right to run the cmdlets identified by the management role entries. To create the role group, run the command:
New-RoleGroup -Name "RG-Sales Helpdesk" -Roles "MR-Sales Admins" -CustomRecipientWriteScope "Scope-Sales OU"
The Roles and CustomRecipientWriteScope parameters identify the Role and Scope we created in the previous steps. These now come together under the RoleGroup.
Running the command Get-RoleGroup returns the specified role group details. Note that a Management Role Assignment is automatically created to link the management role with the role group. This is named using the naming convention <ManagementRoleName>-<RoleGroupName>
Note that the role groups are created in Active Directory under the Microsoft Exchange Security Groups organizational unit:
Now we will add the specialist users IDs as members of the RG-Sales Helpdesk role group. This can be done using the command:
Add-RoleGroupMember "RG-Sales Helpdesk" -Member "Sales Admin1"
We can also check the membership of the role group from Active Directory
Testing Role Based Access Control
Finally, the role group members should be able to run the delegated task against the defined scope. We have the Exchange Management Tools installed on the role group member's machine. From here run and test the commands:
Set-User -Identity "sales1@contoso.com" -MobilePhone 001234567890 -Office SO-141
Set-Mailbox -Identity "sales1@contoso.com" -CustomAttribute1 "Sales Employee"
To check the results run the commands:
Get-User Sales1 | FL Name, MobilePhone, Office
Get-Mailbox Sales1 | FL Name, CustomAttribute1
If you try to run the command on a user that is not in the Sales OU, i.e. not within our management scope, the command fails with the following error message:
'Domain/User' isn't within a valid write scope. Can't perform save operation.
Conclusion
In this article we went through a brief overview of Role Base Access Control (RBAC) in Exchange server 2010. We summarized RBAC components, created management scopes, roles and role groups. Finally we tested our newly acquired rights.
References
RBAC and the Triangle of Power
Understanding Permissions