Intelligent Message Filter, Content Filter, can do more...

WinDeveloper IMF Tune
WinDeveloper IMF Tune
  • Home
  • Security
  • Exchange Server 2010 Role Based Access Control (RBAC)

Exchange Server 2010 Role Based Access Control (RBAC)

Tariq M. Jaber [MCSE 2003, MCTS (ISA 2006, Exchange 2007)]

Tariq M. Jaber [MCSE 2003, MCTS (ISA 2006, Exchange 2007)] Photo

Tariq is a senior Microsoft Systems Engineer. He implemented several Microsoft infrastructure projects for various major companies. He is now focusing on Active Directory and Exchange server administration and implementation.

Cast your Vote
Poor Excellent

In this Article I’ll talk about Role Based Access Control (RBAC), the new permission granting model introduced in Exchange Server 2010. Using RBAC we grant administrators the exact set of permissions required, without handing any additional rights.

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.

Role Based Access Control (RBAC)

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:

Regular/Exclusive scope

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"}

New-ManagementScope

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

Get-ManagementScope

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"

New-ManagementRole

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

Get-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\*"

Get-ManagementRoleEntry

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

Add-ManagementRoleEntry

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"

New-RoleGroup

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>

Get-RoleGroup

Note that the role groups are created in Active Directory under the Microsoft Exchange Security Groups organizational unit:

Microsoft Exchange Security Groups

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"

Add-RoleGroupMember

We can also check the membership of the role group from Active Directory

Role Members

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

Testing Role Based Access Control

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.

Domain/User isn't within a valid write scope

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

User Comments - Page 1 of 1

Vikas kumar 19 Nov 2017 15:05
if a single user is added into multiple customized RBAC group.
how to find what all the permissions does user have on exchange side ?
is there any way to find it
radid najat 17 Jan 2016 11:44
thanks it' s good article
Shameeem 24 Feb 2013 11:16
Thanks! Very well written.
Still have one question.
Is the process done "backward" m meaning you create
1. Where
2. What and then
3. Who?
Regards,
binary 16 May 2012 08:15
thanks, very good article. I was confused about the scope thingy, but now I have a better picture after reading your article.
Pedro 29 Nov 2011 00:33
snakebl, I have the same question...
Pedro 11 Nov 2011 04:56
What Exchange build version you use?
snakebl 6 Dec 2010 04:13
how to set up permissions so that admin user through the exchange console RBAC see only the mailboxes which he can controll, but not all mailboxes from organization.
Copyright © 2005 - 2024 All rights reserved. ExchangeInbox.com is not affiliated with Microsoft Corporation