Role Based Access Control Exchange 2010 Print E-mail

Written by Praveen   
Sunday, 20 June 2010 00:23

Role Based Access Control(RBAC) is the new permission control feature introduced by Microsoft in Microsoft Exchange 2010. By using the RBAC, we can define/control what resources or actions or controls a user or an administrator can access. RBAC in Exchange Server 2010 allows you manage your exchange server permissions effectively. Using a combination of management role groups, management role assignment policies, and management scopes etc, you can grant permissions to administrators and end users. RBAC allows the permission control in broad and granular levels, what an administrator or an end user can do.

RBAC has two primary ways of assigning permissions to users, depends on whether the user is an administrator or specialist or an end user (using Management Role Groups and Management Role Assignment Policies). You may also use direct role assignment to the users.

Now let us discuss what a Management Role Group and Management Role Assignment Policy.

ü  Management Role Assignment Policy

Management role assignment policies associate end-user management roles to users. Role assignment policies consist of roles that control what a user can do with his or her mailbox or distribution groups. When we create an assignment policy we can define all action that a user can do with his or her mailbox. Sometimes a role assignment policy may allow a user to set the display name, configure Inbox rules, update their addresses etc. Another role assignment policy might allow a user to use text messaging, and set up distribution groups. Exchange will have a default role assignment policy, we can create a new one and make it as default if needed. We will not discuss more about management role assignment policy in this post. 

ü  Management Role Group:

Management Role Group is nothing but one more role that are clubbed together to grant permission to the administrators or specialist users. A Management Role Group consists of the following,

  • Management Role Group: The management role group is a special USG (universal security group) that contains users, mailboxes and USGs and some time other role group. You can add or remove members in it, and the roles are assigned to it using the management assignments. The combination of all the roles in the role group defines what a specialist user and administrator those are added to this group can do.
  • Management Role: A management role contains a list of role entries or cmdlets grouped together. Basically a management role is used to define a specific task like recipient management, Mailbox Import Export etc. Read more about Management Role
  • Management Role Assignment: A management role assignment links a role to a role group. Assigning a role to role group grants member of that role group to execute the cmdlets defines in the role.
  • Management Role Scope: A management role scope says where the roles are apply. For e.g. when we assign a role to a group we also can specify the target scope to which the role is assigned for (It can be restricted only to particular OU, Users etc).

The below picture will give an idea how RBAC works.

RBAC Overview

The role assignment links the “Who”, “What” and “Where” together and it gives the effective permission using the Exchange 2010 RBAC. In other word Role entries are put together or grouped into role and then roles are assigned using role assignments to role group by specifying the role scope and the members are added into the role group.

Example:

Scenario - You want to delegate the administration of recipients(create, delete, manage user mailboxes) on a purticular OU in your domain to a Mail Admin user. Will this be possible in exchange 2007 or 2003, I will not say it is not possible. But how easy was the process, not easy isn't it? Now let us see how can we achieve this in exchange 2010 using couple of commands.

Steps in brief:

Note - Exchange 2010 already have number of built in management roles, for the above scenario we can use the role called 'Mail Recipient Creation' which has the following roles entries(you may execute the command get-ManagementRoleEntry " Mail Recipient Creation\*").

Set-ADServerSettings, Remove-Mailbox, Remove-MailUser,Remove-MailContact,Remove-LinkedUser, New-Mailbox, New-MailUser, New-MailContact, New-LinkedUser, Get-User, Get-ThrottlingPolicy, Get-SharingPolicy, Get-RoleAssignmentPolicy, Get-ResourceConfig,Get-OrganizationalUnit, Get-ManagementRoleAssignment, Get-ManagedFolderMailboxPolicy, Get-MailboxDatabase, Get-Mailbox, Get-MailUser, Get-MailContact, Get-LinkedUser, Get-DomainController, Get-ADServerSettings, Add-MailboxPermission, Add-MailboxFolderPermission,

We will use the role 'Mail Recipient Creation' to create the role group.

  1. Create a management role scope(name the scope as ExchangeDictionary Mail Admin)
  2. Create a role group assigning the role ' Mail Recipient Creation' and the scope created in the step1,in the same command we can club the group member addition as well.

That's it! you have achieved the goal! below sections shows the implementation and the testing part of above request.

Step1:Create the scope

Open the Exchange Management Shell and execute the below command.

New-ManagementScope -Name "ExchangeDictionary Mail Admin" -RecipientRoot "ExchangeDictionary.com/ExchangeDictionary-DLs" -RecipientRestrictionFilter { RecipientType -eq 'usermailbox' }

You can verify the role scope using the command get-managementscope cmdlet.

    Command explanation:

  1. Target Organization Unit - ExchangeDictionary.com/ExchangeDictionary-DLs
  2. Type of target object -  User Mailbox
  3. Scope Name - ExchangeDictionary Mail Admin

Step2:Create the role group by assigning role, scope and member into it

Execute the below command to create a new role group for delegating the mail recipient administration permission to the user PraveenB

New-RoleGroup -Name "ED Mail Admin" -Roles "Mail Recipient Creation" -CustomRecipientWriteScope "ExchangeDictionary Mail Admin" -Members praveenb

The role group has been successfully created now, you can verify the group using either ADUC or exchange management shell.

     Command explanation:

  1. Management Roles used(What) -  Mail Recipient Creation (you can use more roles separated by comma)
  2. Role Group Name - ED Mail Admin
  3. Target Scope(where) - ExchangeDictionary Mail Admin
  4. Member of the new role group(Who) - PraveenB

Test the configuration:

1. Login to the server using the ID PraveenB (note - you may have to add the user into remote desktop user group).

2. Open the Exchange Management Console(you can even open the management shell to test it).

EMC_Org_level_permission

From the above screen shot you can see that the user does not have permission to view or edit any Organization configuration.

3. Expand Recipient Configuration/Mailbox

4. Create a new user by not specifying an OU for creating the new mailbox, let it take the default location, "Exchangedictionary.com/Users" ,.

Continue with the wizard and on finish page you will receive an error as shown in the below screen shot.

creation-wo-OU-2

The error message clearly says that ExchangeDictionary.com/Users/ExchangeDictionary isn't within the write scope, we have created the management scope with the following OU path 'ExchangeDictionary.com/ExchangeDictionary-DLs'.

5. Now let us create the user by specifying the OU "ExchangeDictionary-DLs".

creation-with-OU-1

We have selected the OU as 'ExchangeDictionary.com/ExchangeDictionary-DLs". Continue with the user creation wizard and now let us look at the wizard stage"finish".

creation-with-OU-2

Now let us think about the permission model in exchange 2007 and earlier, we were using the Access Control List. Now in Exchange 2010 we use the easy to use RBAC not the ACLs. Hope this  was helpful in understanding the concept of RBAC.

-Praveen

AddThis Social Bookmark Button
 

Comments  

 
0 # Mac 2010-12-29 21:58
Hi Praveen,

Thanks for the details excplanation how RBAC works. I have one requirement i hope you will help to resolve the issue. I want to give permission to one user on DL wherein he can modify the same. Please assist me how to procced.
Reply | Reply with quote | Quote
 
 
0 # Praveen 2011-01-03 20:57
Mac,
Thanks!

You requirement is simple, you do not have to do this via RBAC. Simply add the user as a Group Manager to the DL which you need to grant permission. A group manager can fully administer the group itself. He can use the Exchange Control Panel(if you have exchange 2010) to manage these DLs, read http://www.exchangedictionary.com/index.php/Latest/exchange-control-panelexchange-2k10.html.
Reply | Reply with quote | Quote
 
 
0 # muniraj pachappan 2011-09-02 00:43
Hello Praveen

Thanks for your Blog !
we have requirement to grant access to L2 level exchange admins who should be able to run the OAB update, could you please assist
Thanks are regards
Muniraj
Reply | Reply with quote | Quote
 
 
0 # Praveen 2011-09-02 16:58
Muniraj,

To delegate any extra permission, you need to identify the powershell command which used to perform the action. In this case it is Update-OfflineAddressB ook

Update-OfflineAddressB ook cmdlet is available on the role "Address Lists" and is assigned to the Organization management role group by default. You can add the management role "Address Lists" into the L2 admin role group either directly or by customizing according to the requirement. To know more about Management role, read http://www.exchangedictionary.com/index.php/Articles/create-new-management-role-rbac.html
Reply | Reply with quote | Quote
 
 
0 # Louis 2011-10-09 00:26
Good day Praveen,

I have a problem when I create a mailbox user. In "User logon name" textbox, I named abc but next textbox(e.g : @local.com)is nothing, so I can not select a domain. Can you help me fix this problem ? :sad:

Sorry about my english.

Thanks so much
Reply | Reply with quote | Quote
 
 
0 # Praveen 2011-10-14 05:17
Hello Louis,

I did not clearly understand the issue, normally the domain name available as a drop down. You may try using the shell command to create a user to test this..

New-Mailbox -UserPrincipalNa me username@yourdo main.com -Alias Username -Name TestUser -Database "Database Name" -OrganizationalU nit Users

enter the password when prompts.. let me know how it goes..
-Praveen
Reply | Reply with quote | Quote
 
 
0 # Pedro 2011-11-11 18:42
Great post Praveen!

I have a problem when I define scopes to Role Groups... Members users of role groups, can do actions out of your scope!

My Exchange versión is SP1 (build 218.15), and I review this KB

http://support.microsoft.com/kb/2608646

What Exchange build version you use?
Reply | Reply with quote | Quote
 
 
0 # Praveen 2011-11-16 10:11
Thanks Pedro,

Here I have shared one such reported problem with the scope, i.e. related to the Mailbox permission cmdlets, which are executed outside the defined scope. the same is explained in the below Technet article.
http://support.microsoft.com/kb/2549289

If you are talking about the same, then applying RU6 should resolve this issue(did not tried it yet).

Let me know the scenario that your scope has no impact. I would suggest you to revisit the steps when creating the scope.. :-)
-Praveen
Reply | Reply with quote | Quote
 
 
0 # Amit 2012-01-20 14:50
Hi Praveen,

We are moving from Exchange 2003 to Exchange 2010.

we want to provide only move mailbox permissions to our migration engineers so they can access user emails.
please let me know how can we tweak RBAC to provide only move mailbox permissions to our engineers so they can not provide themselves full access to user mailboxes.

Regards
Amit
Reply | Reply with quote | Quote
 
 
0 # Praveen 2012-01-22 15:10
Mailbox move cmdlets are available in the role "Move Mailboxes". Create Role group for this and add the migration engineers. Also add them into View-Only Organization Management group. I did not try this, however this setup may work.

read http://www.exchangedictionary.com/index.php/Articles/create-new-management-role-rbac.html article to know more about roles.
Reply | Reply with quote | Quote
 
 
0 # Mojo 2012-01-25 04:31
Could you please explain how you can assign the permissions described above to a specific database?

We want to delegate mailbox creation to a specific user(s), in a specific OU and then to a specific database in Exchange 2010.

Thanks!
Reply | Reply with quote | Quote
 
 
0 # _Praveen 2012-01-30 13:27
@ Mojo,

You can use '-DatabaseRestric tionFilter' switch with the New-ManagementScope cmdlet.

e.g. '-DatabaseRestric tionFilter {Name -Like "ED*" }'; this will restrict the scope to DBs which starts with "ED"
-Praveen
Reply | Reply with quote | Quote
 
 
0 # Nick Lloyd 2012-01-30 20:39
Thanks Praveen, very useful. I also have the issue of the domain drop-down box being blank but adding @domain.local to the new user name allowed me to create a mailbox.
Reply | Reply with quote | Quote
 
 
0 # Aijaz 2012-03-27 12:03
Hi Preveen,

i m atrying to give users permissions to create users with mailbox, etc in ex2010. is it okay if i add them to the recipient role, and they can user EMC to perform their job.

Please Advice.

Regards
Aijaz
Reply | Reply with quote | Quote
 
 
0 # Praveen 2012-03-27 16:12
Yes, it should be fine. You may add them to Recipient Management role group, they should be able to perform creation/deletion and other recipient administration activities.

-Praveen
Reply | Reply with quote | Quote
 
 
0 # Dilip Subramanian 2012-06-02 16:13
If we implement RBAC , what would be the impact of existing permission given to the admins through groups ?
Reply | Reply with quote | Quote
 
 
0 # -Praveen 2012-06-02 16:26
RBAC is the default permission model. When you say implement, you are just creating additional permission groups and adding members into it. As long as you don't play with the default roles and role group, there will not be any impact to the current permission levels...
Reply | Reply with quote | Quote
 

Add comment


Security code
Refresh

Read In

ARCHIVES

VISITORS

mod_vvisit_countermod_vvisit_countermod_vvisit_countermod_vvisit_countermod_vvisit_countermod_vvisit_counter

Online : 6
Your IP: 184.73.74.47
,

Follow Us