Permissions and Role Based Access Control (RBAC) – Part II

Overview

In Part I, we talked about how you can configure broad permission settings in RBAC (Role Based Access Control) by employing Predefined Role Groups through the Exchange Control Panel’s graphical user interface. However, you will no doubt encounter situations wherein you will need to perform permission settings on a more granular level than what the Predefined Role Groups can support. This is where the Exchange Management Shell becomes more suitable.

For instance, what if you want an admin to make transport rules but don’t want him to have anything to do with retention rules and message classifications? Obviously, assigning him to the Records Management role group – which, in addition to transport rules, also covers other compliance features like retention policies and message classifications – would not suffice because it would grant him more permissions than you want him to have.

Note: You may see brief descriptions of the Predefined Role Groups in Part I of this article: Exchange 2010 RBAC: Role Based Access Control.

Viewing RBAC Settings Through the Exchange Management Shell

At this point, I’ll show you first how you can view, in the Exchange Management Shell, the same information that you see in the Exchange Control Panel.

For example, while you can use the Exchange Control Panel (see screenshot immediately below) to view Assigned Roles belonging to the Recipient Management role group,

you can likewise view that same information in the Exchange Management Shell by typing:

Get-RoleGroup “Recipient Management” | fl.

Here’s the result when you press the “Enter” key. Notice that the Assigned Roles (enclosed in a red box) are exactly the same items that you saw two screenshots earlier. Aside from the roles, you’ll also see a short description of the Recipient Management role group, its members (none at this point), and a bunch of other related information.

Now, what you just saw did not reveal any advantage the Exchange Management Shell has over the Exchange Control Panel. To demonstrate the full potential of the Exchange Management Shell, we would have to make granular settings on RBAC, and that’s what we’re going to show later in this article.

Sample Scenario

First , let’s take a sample scenario:

Your company has just hired some Exchange Junior Administrators through an internship program and you want to give those interns a specific set of permissions to configure certain recipient details, namely: Office, Phone no., Mobile no., Department and Managers.

This can be easily done by assigning each junior admin the full Mail Recipients role. However, doing so would also enable them to have access to other permissions found within that role, which is not part of the plan. So that you can see how risky it really is to assign the full Mail Recipients role, let’s view all the Role Entries (cmdlets and parameters) associated with this particular role.

Open your Exchange Management Shell and type:

Get-ManagementRoleEntry “Mail Recipients*”

You’ll see something like this:

Scrolling down will reveal an even larger number of role entries. Surely, you wouldn’t want your junior admins to have access to all those cmdlets and parameters. The ideal solution would be to create a child role of the Mail Recipients role and grant only the permissions needed for the specific task on hand.

Planning RBAC and Mapping Out the Cmdlets To Be Used

Before you dive into the Exchange Management Shell and execute your Cmdlets, it’s best to plan and determine which ones to use. When it comes to planning RBAC, refer to the RBAC Triangle of Power. See Part I of this article for guidance: Exchange 2010 RBAC: Role Based Access Control.

Scope (Where)

The first thing to define is the Scope (a.k.a. the Where). Normally, you would need the New-ManagementScope cmdlet to define a new scope. However, since we are going off an existing parent role, our new management role will simply inherit the scope of that parent role. Hence, there is no need to explicitly define a scope and, subsequently, no need to use the New-ManagementScope cmdlet. Instead, just like its parent role, it is understood that the newly created role will provide Read/Write for recipient and configuration objects spanning the entire organization.

Role (What)

Next, we need to define the Role. Because the Mail Recipients role, which we want our new role to inherit from, comes with a large number of entries that we don’t need, our method would involve:

–Using the New-ManagementRole cmdlet

• Giving the new management role a name (ex: “Exinterns”)
• Declaring which parent role it should inherit from (ex: “Mail Recipients” role)

–Removing practically all of the entries inherited from the Mail Recipients role and putting back only those that are needed using the Get-ManagementRoleEntry, Remove-ManagementRoleEntry, and Add-ManagementRoleEntry cmdlets.

Role Group (Who)

Finally, we need to define the Role Group, or the ‘Who’, using the New-RoleGroup cmdlet. This last step essentially glues this step and the other two that preceded it (the ‘Where’ and the ‘What’) into one cohesive Role Assignment.

That said, you’re now ready to configure RBAC settings in the Exchange Management Shell.

Configuring RBAC Settings Through the Exchange Management Shell

Remember that we don’t need to define the Scope in this example, so let’s proceed with defining the Role.

To create a role named “Exinterns” that inherits from the Mail Recipients role, type in:

New-ManagementRole -Name “ExInterns” -Parent “Mail Recipients”

After pressing “Enter”, you’ll see something like this:

which means you’ve just successfully created the ExInterns role.

Next, we’ll get all the management role entries of the ExInterns role and remove them, except for one. That’s because the system will always require you to leave at least one role entry.  We will leave the Get-User cmdlet because we want the ExInterns role to make extensive use of the Set-User cmdlet, which can only work effectively when applied in conjunction with Get-User. Type in:

Get-ManagementRoleEntry “ExInterns*” | Where {$_.name -ne “GetUser”} | RemoveManagemRoleEntry

Basically, Set-User will enable the Interns to set configurations on the mailbox. But it would be more convenient for the Interns to do that if they could first see the things they need to set.

As soon as you press “Enter”, you’ll see a confirmation notification that goes like this:

You’ll be encountering a lot of these confirmations, so if you’re sure with what you’re doing, just press ‘A’ for Yes to All. Otherwise, you’ll have to press either ‘Y’ for Yes, ‘N’ for No or ‘L’ for No to All.

When you’re done with all the confirmations, you may verify that you were successful by entering:

Get-ManagementRoleEntry “ExInterns*”

As you can see, unlike the first time we executed this cmdlet (see the fourth screenshot from the top), the new ExInterns role no longer has the role entries it initially inherited from its parent role.

You are now ready to add the role entry that will enable the Exchange Interns to configure the Office, Phone no., Mobile no., Department and Managers recipient details. To do that, type:

Add-ManagementRoleEntry “ExInternsSet-User” -Parameters Office,Phone,Mobilephone,Department,Manager

Had you omitted the

-Parameters Office,Phone,Mobilephone,Department,Manager

the Exchange Interns would have had access to all the parameters of the Set-User cmdlet. Thus, not only have you confined the Interns’ capabilities to the Get-User and Set-User cmdlets, but also specifically to the Set-User’s Office, Phone, Mobilephone, Department, and Manager parameters.

Finally, we create the Role Group (ex: “ExInterns”) and specify the Role we are going to assign to it (ex: also “ExInterns”) by entering:

New-RoleGroup “ExInterns” -Roles “ExInterns”

This final action creates the Role Assignment: ‘ExInterns-ExInterns’.

Now, if you want to check, you can list all your current Role Groups using Get-RoleGroup. There you’ll find the newly created ExInterns role group.

Having done that, you can now assign your Interns to the ExInterns role group.

Adding Users to the Role Group

Although you can add users to a role group using the Exchange Management Shell, that task is easier done using the Exchange Control Panel. So, navigate back to your Exchange Control Panel and go to the Administrator Roles tab. Sometimes, you need to click the Refresh button to see the newly added Role Group.

Find the ExInters role group and double-click on it.

This should bring you to that role group’s window. Click the Add button to add a new member.

You can now select one or more members to add to the role group. Each selected user will be displayed in a text box (see rectangular box below). Click the OK button when you’re done.

When you’re back at the role group’s window, you’ll see the newly added members there. Click Save if you’re done adding.

Summary

Whereas older versions of Exchange had only a few administration groups to choose from, the new RBAC permissions model in Exchange Server 2010 allows you to define broad, or more granular, assignment of permissions to administrators. This flexibility in role assignment offered by Role Based Access Control, enables you to set up roles which more accurately reflect the actual roles that administrators perform within your organization.