2010-07-08 1 Comment
This is part two in my series of posts about Role Based Access Control. Again, if you find an error of any sort, have any questions or thoughts about it please do not hesitate to drop a comment or contact me. And don’t be afraid to do, I’m not as much of a loony as you might think…
We will jump directly into Management Role Scopes, continue with Management role groups and finish off with Management Role Assignment Policies.
Management Role Scopes
A scope makes it possible for you to define the impact of a role assignment. It enables control over which objects in your organization that the users can access and manipulate. There are a number of different scopes that you can define when adding roles to a role group. These scopes must be defined before you use them in a role group assignment. All roles have management scopes and they can be one of the following two:
A regular scope determines where, in Active Directory, objects can be modified by users assigned to the management role. As a basic rule you can say that a management role determines what you can modify and a role scope determines where you can modify.
This type of scopes behaves almost the same as a regular scope but with exclusive you can also deny user access to specific objects.
implicit scopes are the default scopes predefined in Exchange Server 2010. They can be inherited from a management role or you can define which scope to use. More information about implicit scopes here: http://technet.microsoft.com/en-us/library/dd335146.aspx#ImplicitScopes
Explicit scopes are set by you and enables you to control which objects a management role can modify. These can be one of the following.
Predefined relative scopes for easy management. There are three of different relative scopes:
- Organization – The role can create or modify recipient objects across the Exchange organization.
- Self – The role can modify only the properties of the current user’s mailbox.
- MyDistributionGroups – The role can create or modify distribution list objects owned by the current user.
Scope’s that that you can create and modify yourself. This is a powerful way of defining the scope for a management role on a granular level. For example, you can define an Organizational Unit, a recipient and much more. The scope is created using the New-ManagementScope command. More information on this can be found here: http://technet.microsoft.com/en-us/library/dd638110.aspx
Management Role Groups
Management role group is in fact universal security groups (USG). They are used to simplify the assignment of management roles enabling you to add permissions for multiple users at the same time. All members of a management role group will have the same rights and are assigned the same set of roles
Role group layers
Microsoft has implemented a model consisting of layers that makes it quite easy to understand how role groups work. The model includes the following layers:
- Role holder – A role holder is a mailbox that is a member of a role group. All assignments of management roles applied to a role group will affect the member mailbox, Role Holder, when the mailbox is added to a group.
- Management role group – Eniversal security groups (USG) used when assigning permissions for multiple mailboxes.
- Management role assignment – Assignments is the link between management roles and management groups. When you assign a role to a group, all members in that group will be granted the included permissions. Role assignments can be both scoped and un-scoped.
- Management role scope – The impact on a role assignment when you assign a role with a scope to a role group. Can consist of recipients, OU’s or servers.
- Management role – Management Role entries grouped together forms a Management Role. Roles define the tasks that can be performed by the members of a role group.
- Management role entries – Individual entries that can provide access to cmdlets, scripts, and special permissions. Can be a single cmdlet and its parameters.
Assigning roles to a role group
After you have decided the scope you want to use in your role assignment you can proceed to add the role to a role group. First, here is how to create a role assignment with no scope:
New-ManagementRoleAssignment -Name <assignment name> -SecurityGroup <role group name> -Role <role name>
If you want to create a role assignment using a predefined scope:
New-ManagementRoleAssignment -Name <assignment name> -SecurityGroup <role group name> -Role <role name> -RecipientRelativeWriteScope < MyGAL | MyDistributionGroups | Organization | Self >
And if you want to use a custom filter-based scope:
New-ManagementRoleAssignment -Name <assignment name> -SecurityGroup <role group name> -Role <role name> -CustomConfigWriteScope <role scope name>
Management role assignment policies
Management Roles Assignment policies consist of one or more user management roles. This is used to control the end-users permissions to manage their personal Exchange Server 2010 mailbox and distribution group configuration.
Default Role Assignment Policy
There are two types of policies in Exchange Server 2010, Default and Explicit. If a role assignment policy is not assigned to a new mailbox the default role assignment policy kicks in and provides users with a set of basic and common permissions. A role assignment policy can be applied to a user’s mailbox with either the New-Mailbox or Enable-Mailbox command.
You can also define your own role assignment policy as a default policy. This is done using the Set-RoleAssignmentPolicy command. Doing so will apply the new default role assignment policy to all new mailboxes, not the current one already created. You can also change the default role assignment policy, this is not something I recommend since it is good to have for reference and as a backup if you need to remove your own policy.
To apply a new policy to a mailbox you must use the Set-Mailbox cmdlet, this updates the mailbox with the new setting.
Explicit Role Assignment Policy
When you assign a role assignment policy manually using the RoleAssignmentPolicy parameter on the New-Mailbox, Set-Mailbox, or Enable-Mailbox cmdlets this policy is called an explicit role assignment policy.
That’s it for this time!
In part 3 of this series I will give you examples, examples and more examples. I’m doing my best to get it done as soon as possible and it will be ready in a couple of weeks. Thanks for reading, and as always just let me know if you have any thoughts or questions!