If you would like to read the other parts in this article series please go to:
- Exchange 2010 Role Based Access Control (Part 1)
- Exchange 2010 Role Based Access Control (Part 2)
- Exchange 2010 Role Based Access Control (Part 3)
Introduction
In this article series you have seen how users can be added to management role groups to grant them permissions to run the cmdlets that are linked to the management role groups. This method is typically used to grant administrators and specialist users the permissions that they need to perform their duties. For normal users who are not administrators or specialist users, management role assignment policies can be used. These management role assignment policies are typically used to grant users permissions to manage their own mailboxes as we shall see within this part of the overall RBAC article series.
Management Role Assignment Policies
All mailboxes are assigned a default role assignment policy unless a specific role assignment policy is otherwise specified. The default role assignment policy is named, rather unsurprisingly, Default Role Assignment Policy and its link to a mailbox can be seen by examining the output of any mailbox and looking for the RoleAssignmentPolicy attribute. For example, to examine the configuration of the mailbox belonging to the user Neil and filter the output for the RoleAssignmentPolicy attribute, the following cmdlet can be used:
Get-Mailbox Neil | fl RoleAssigmentPolicy
The result of running this cmdlet can be seen in Figure 14.
Figure 14: Default Role Assignment Policy
We will shortly examine the contents of the Default Role Assignment Policy to see what it contains and which permissions are granted. However, although we won’t be covering the creation of custom role assignment policies within this particular article series, it is worth covering at this point how you can change the management role assignment policy that is linked to a mailbox. For an existing mailbox, you can use the Set-Mailbox cmdlet with the RoleAssigmentPolicy parameter to change the management role assignment policy. For example, to set Neil’s mailbox to use a management role assignment policy called New Policy the following cmdlet could be used:
Set-Mailbox Neil –RoleAssignmentPolicy ‘New Policy’
For new mailboxes, the RoleAssignmentPolicy parameter of the New-Mailbox cmdlet can be used to specify the name of the management role assignment policy to be used when that mailbox is first created. If no specific policy name is applied when creating a new mailbox, the default management role assignment policy will be applied.
Management Role Assignments
If you have been reading the previous parts of this article series, you will remember that management role assignments are links between management role groups and management roles. In the context of management role assignment policies, management role assignments are also used and function as the link between management roles and management role assignment policies. You will also remember that management roles essentially hold a group of cmdlets that the user is allowed to run.
Let’s take a closer look at the Default Role Assignment Policy and see which management role assignments are linked to it. Ordinarily, you might be tempted to bring up the properties of the Default Role Assignment Policy via a cmdlet such as:
Get-RoleAssignmentPolicy –Identity ‘Default Role Assignment Policy’
The result of running this cmdlet can be seen in Figure 15.
Figure 15: Properties of the Default Role Assignment Policy
As you can see from Figure 15, the output does present some useful information such as the description of the policy but it doesn’t really tell you anything meaningful such as the management role assignments linked to the policy. To get this information, we can use the Get-ManagementRoleAssigment cmdlet together with the RoleAssignee parameter. By specifying the RoleAssignee as the Default Role Assignment Policy, we can see all management role assignments that are linked with the default policy. Ordinarily, a lot of information is returned when executing this cmdlet so in the example cmdlet below we can filter the output to only present the name and role information:
Get-ManagementRoleAssignment –RoleAssignee ‘Default Role Assignment Policy’ | fl Name,Role
You can see the result of running this cmdlet in Figure 16:
Figure 16: Assigned Management Roles
Management Roles
The output of Figure 16 shows you that the management role assignment policy called Default Role Assignment Policy is linked with five management roles called MyBaseOptions, MyContactInformation, MyVoiceMail, MyTextMessaging and MyDistributionGroupMembership.
Each of these management role names should be reasonably self-explanatory in what the roles are designed to allow the user to do but the table below serves to emphasize this information as it contains the five management role names together with their default descriptions.
|
Management Role |
Description |
|
MyBaseOptions |
This role enables individual users to view and modify the basic configuration of their own mailbox and associated settings. |
|
MyContactInformation |
This role enables individual users to modify their contact information, including address and phone numbers. |
|
MyVoiceMail |
This role enables individual users to modify their voice mail settings. |
|
MyTextMessaging |
This role enables individual users to create, view, and modify their text messaging settings. |
|
MyDistributionGroupMembership |
This role enables individual users to view and modify their membership in distribution groups in an organization, provided that those distribution groups allow manipulation of group membership. |
Table 1: Assigned Management Role Descriptions
In order to keep this article reasonably short, let us now focus on looking deeper at just one of the management roles listed in Table 1, namely the MyContactInformation management role. In Figure 11 in part three of this article series we saw the generic Exchange Control Panel page within Outlook Web App. In the centre of this screen it is possible to click the Edit button to allow the editing of the user’s own contact information as you can see from Figure 17.
Figure 17: Editing Contact Information
The ability for the users to edit their own contact information is made possible by the fact that the MyContactInformation management role is assigned to the users. Let’s take a deeper look at how the MyContactInformation management role is constructed. First of all, let’s take a closer look at the actual management role assignment called MyContactInformation-Default Role Assignment Policy that you can see listed in Figure 16. To do this, we can run the following cmdlet:
Get-ManagementRoleAssignment ‘MyContactInformation-Default Role Assignment Policy’ | fl
You can see the result of running this cmdlet in Figure 18.
Figure 18: Management Role Assignment Details
You may remember from earlier in this article series that the Mailbox Search-Discovery Management role assignment had RecipientReadScope and RecipientWriteScope values of Organization, meaning that the scope of this management role assignment is set across the entire Exchange organization. Compare that information to the RecipientReadScope and RecipientWriteScope values seen in Figure 18 above, where you will see that the scopes for the MyContactInformation-Default Role Assignment Policy management role assignment are set to Self, meaning that the assigned roles can only modify the local mailbox information rather than the entire Exchange organization. This makes sense, as you may remember right back in part one of this article series that we said management role groups are used for overall administrators or specialist users, whereas management role assignment policies are used for the users themselves; clearly an individual user only requires permissions to modify his or her own information.
As for the actual cmdlets that the user will be able to run, we can examine this information by using the Get-ManagementRole cmdlet to examine the properties of the MyContactInformation management role and filter the output to show only the RoleEntries parameter. A suitable cmdlet is:
Get-ManagementRole MyContactInformation | fl RoleEntries
You can see the result of running this cmdlet in Figure 19.
Figure 19: The MyContactInformation Management Role
You can see from Figure 19 that this management role grants the user the rights to run the Set-User cmdlet with many different parameters such as the City, MobilePhone, Office and PostalCode parameters. It also grants the user the right to run the Get-Mailbox cmdlet with the Identity parameter. You may also remember from part three of this article series that it is easier to use the Get-ManagementRoleEntry cmdlet to display this information. For example, the following cmdlet could be used:
Get-ManagementRoleEntry MyContactInformation\* | ft –AutoSize -Wrap
The result of running this cmdlet is shown in Figure 20 where you can see that the cmdlet and parameter information is displayed much more clearly.
Figure 20: Get-ManagementRoleEntry Results
To demonstrate that the MyContactInformation management role in conjunction with the management role assignment does indeed allow a user to edit their own contact information, let’s prove this by removing the management role assignment. You probably will not want to do this in your production environment but this exercise can be useful to understand how all the various RBAC components work together. Consider Figure 21 where you can see that we first confirm that the Default Role Assignment Policy contains the management role assignment called MyContactInformation-Default Role Assignment Policy.
Next, the management role assignment policy can be removed via this cmdlet:
Remove-ManagementRoleAssignment ‘MyContactInformation-Default Role Assignment Policy’
The Get-ManagementRoleAssignment cmdlet is then re-run to confirm that the management role assignment is no longer available.
Figure 21: Removing the Management Role Assignment
The result of making this change is that, the next time the user logs onto OWA and attempts to edit their own contact information, it is not possible to edit the various fields as you can see from Figure 22.
Figure 22: Unable to Edit Contact Information
Summary
That concludes this four-part article series on an introduction to the RBAC model within Exchange 2010. In this article series you have seen how management role groups and management role assignment policies are used to assign permissions within Exchange 2010. I’ve taken the time to look at a specific management role group and a specific management role assignment policy, and broken these down into the various components in order to understand how they are used to assign permissions. This will allow future articles on customized solutions to be better understood.
If you would like to read the other parts in this article series please go to:
