Allow Users To Manage Distribution Groups Without Creating New Ones

In a previous post we discussed a scenario where users were delegated the capability to create Mail Enabled Contacts in Active Directory using a custom RBAC role.  As part of the solution, we enabled the MyDistributionGroups Role.  While this may meet the needs of most organisations it does introduce one issue where users who are assigned such a  Role Assignment Policy can edit Distribution Groups they own but also create new ones.

This post is based on Exchange 2010.  If you would prefer an Exchange 2013 specific post, please view this entry.

Update 20-1-2014: Corrected PowerShell code to add a missing bracket in $Roles = (Get-RoleAssignmentPolicy -Identity "Default Role Assignment Policy").AssignedRoles

Update 1-6-2015: Link to an Exchange 2013 specific version of this post was added.

How can we solve the challenge of allowing users to managed Distribution Groups that they own, but also prevent them from removing or adding new ones?  Well, it’s a similar story to the previous blog – we will create a custom RBAC Role!

One thing that is a little different is that the RBAC configuration for the items related to configuring your own mailbox is stored within a Role Assignment Policy.  The same terminology applies but we need to be clear that end-user RBAC is contained within a Role Assignment Policy and administrator RBAC lives in Management Roles.

This scenario calls for having multiple Role Assignment Polices as each will have a different configuration.  For example you may envision the following:

1. Default Role Assignment Policy – can edit zero Distribution Groups
2. DG-Management Role Assignment Policy – can edit Distribution Groups owned by user, cannot create new ones.
3. DG-Full-Management Role Assignment Policy – can edit Distribution groups owned by user, and can create new ones.

We will create option #2 in this blog.  Option1 is the initial setup with the Default Role Assignment Policy, and Option3 can be done by following the steps in the previous blog to simply enable the MyDistributionGroups Role in the relevant Role Assignment Policy.

Let’s get jiggy with it, and create a new Role Assignment Policy!  **

Create New Role Assignment Policy

Let’s create a new Role Assignment Policy called DG-Management.  We want to mirror the existing Default Role Assignment Policy, as a mailbox can only be assigned a single Role Assignment policy and we need to ensure that the user can perform all required activities on their mailbox.  This can be customised to suit your requirements, in this example we will copy from the Default Role Assignment Policy, but this is not required.

We can write down the roles assigned to the Default Role Assignment Policy and manually add them, or alternatively we can save the Default Role Assignment Policy  roles to a variable.  We can then provide this variable as the list of roles when the new Role Assignment Policy is created.  let’s save the Roles assigned to the variable $Roles.

$Roles = (Get-RoleAssignmentPolicy -Identity "Default Role Assignment Policy").AssignedRoles

$Roles will then contain the following Roles:

MyBaseOptions
MyContactInformation
MyVoiceMail
MyTextMessaging
MyDistributionGroupMembership

When creating the new Role Assignment Policy called DG-Management, we provide the $Roles variable which contains the saved roles.

New-RoleAssignmentPolicy –Name DG-Management –Roles $Roles

Create Custom Management Role

All the Management Roles that can be assigned to a Role Assignment Policy  are prefixed with “My” to indicate that they are for user RBAC.  This is a list of the Exchange 2010 roles starting with the prefix “My”:

The Management Role Entries for MyDistributionGroups is shown below along with showing that this is a built-in role and is intended for end user purposes.

In order to stop users with this Management Role creating and deleting Distribution Groups, we need to remove the “New-DistributionGroup” and “Remove-DistributionGroup” cmdlets.  As before, the built-in RBAC roles are read only so we need to make a writable copy.

New-ManagementRole -Name "Edit-Existing-DG-Only" -Parent MyDistributionGroups

Then removing the new and remove distribution group cmdlets:

Remove-ManagementRoleEntry Edit-Existing-DG-OnlyNew-Distributiongroup

Remove-ManagementRoleEntry Edit-Existing-DG-OnlyRemove-Distributiongroup

Checking to see the current Management Role Entries, note the New and Remove cmdlets are gone:

Once happy, will assign this custom Role to our new Role Assignment Policy.

New-ManagementRoleAssignment -Policy "DG-Management" -Role Edit-Existing-DG-Only

Note that we can do most RBAC work in ECP after Exchange 2010 SP1, though I still prefer PowerShell as that was what I had to learn initially.  Old dog, new tricks etc…..

Testing & Validation

In order to test the work we have done, the Role Assignment Policy must be assigned to a mailbox.  As mentioned above a mailbox can only have a singe Role Assignment Policy at any given time.  You can have multiple Role Assignment Policies, and assign one to a given mailbox.  You do not have to explicitly assign a Role Assignment Policy, and this is the default behaviour for a mailbox.  If you do not explicitly state which one should be used when creating  or moving a mailbox to Exchange 2010, Exchange will use the one marked as default.  Note it is not necessarily the one called “Default Role Assignment Policy”;  that one is created by default, is the only one by default and is initially marked as default.  This can be changed to suit your needs.  Let’s say you create a Role Assignment Policy that you want 95% of the users to have as it’s your base standard then you can mark it as the default.

Set-RoleAssignmentPolicy -Identity "Contoso Standard" -IsDefault:$true

Viewing all of the Role Assignment Policies shows Contoso Standard is the default.  Mailboxes created will now leverage the Contoso Standard Role Assignment Policy unless explicitly stated otherwise.  Mailboxes created prior to this point will continue to use their existing Role Assignment Policy and will not automagically change to this new default policy.

Let’s set our test mailbox (user-20) to explicitly use the DG-Management Role Assignment Policy

Set-Mailbox -Identity user-20 -RoleAssignmentPolicy DG-Management

When user-20 then opens up ECP, they have the following capabilities, note that there is no New or Delete button under “Public Groups That I Own”.

For a Distribution Group to show up, it must have the ManagedBy attribute set.  In this test org there are several DGs, but only the ones that user-20 has ManagedBy appear.

Conclusion

We can see that the basic steps to tune and customise RBAC are very similar to the previous blog on delegating Mail Enabled Contact creation.  There are some differences as we are creating a custom Management Role to be used as part of a Role Assignment Policy though all the concepts still apply.

Cheers,

Rhoderick

** – Forget the music and stuff Will Smith, where is Independence Day 2 anyway ?!?!?