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.
Update 20-1-2014: Corrected PowerShell code to add a missing bracket in $Roles = (Get-RoleAssignmentPolicy -Identity "Default Role Assignment Policy").AssignedRoles
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:
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.
So let’s get jiggy with it, and create a 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
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
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 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
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…..
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.
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.
** – Forget the music and stuff Will Smith, where is Independence Day 2 anyway ?!?!?
If you would like to have Microsoft Premier Field Engineering (PFE) visit your company and assist with the topic(s) presented in this blog post, then please contact your Microsoft Premier Technical Account Manager (TAM) for more information on scheduling and our varied offerings!
If you are not currently benefiting from Microsoft Premier support and you’d like more information about Premier, please email the appropriate contact below, and tell them you how you got introduced!
For all other areas please use the US contact point.
Hi. Thanks for a good explanation on what, how and why.
Its almost the same as this blog from 2009, which I have used a lot.
You're correct that it is similar, but I wanted to take the concepts and expand some aspects. The other reason that I have this here is when I teach Exchange workshops to Microsoft Premier customers, I can point them to a single place and I have the links to hand :)
hi thanks for the article.
I have a question. I want to delegate to poeople Group ownership, but I dont want they can adding vip person to this groups. How can I provide adding someone to an Distribution Group even by Group Manager
UTG - I don't think that you will be able to block this unless you use a different product like FIM (though that needs to get validated) as Exchange RBAC does not restrict the recipient read scope.
Even if you place an Exclusive scope around the VIP OU, I doubt that it will prevent other DG managers from adding VIP users to their groups.
according to your blogpost I've managed to accomplish this behaviour, but I ran into issue with editing groups. If I try to edit group that is hidden from GAL, OWA shows error "The operation couldn't be performed because object 'be94dda3-7bb3-4a28-9fbe-ef6e6f503d76' couldn't be found on 'dc1.test.local'." If I unhide that group, managing starts working. May I ask you for any advice how to manage even hidden groups this way?
Back after Christmas holidays!
Is this still something you are interested in working on? I can't honestly remember if I ever tried to do this with a hidden group (probably not though).
When I run the command New-RoleAssignmentPolicy -Name DG-Management -Roles $Roles, I get this error: The "MyDistributionGroupMembership-Default Role Assignment Policy" management role can't be found.
Thanks for the article.
If you run $Roles what is returned at that point please? Do you get a listing of Roles?
Hi Rhoderick, Yes, I get the listing of roles.
Hi Guy, I went back to my lab on this. That code above is not right.
If you run
Get-RoleAssignmentPolicy ("Default Role Assignment Policy").RoleAssignments | Select identity
That returns the RoleAssignemntPolicies - not the individual roles -- which is what we want.
I'll go back to my other machine later and see what I was playing at!
In the meantime try this please.
$managementRole = Get-RoleAssignmentPolicy ("Default Role Assignment Policy")
$Roles = $managementRole.AssignedRoles
if you then echo out $Roles, you should see this:
Then you should be able to use $Roles as the -Roles parameter in the New-RoleAssignment command.
And I see formatting is now lost :( let me retry that....
Bah - not working with IE11, IE10 or Firefox. I'll file this as an issue on the internal blog support site then.....
Went back a looked at this - there is a missing bracket in the original command, and that is messing it up - sorry!
$Roles = (Get-RoleAssignmentPolicy "Default Role Assignment Policy").AssignedRoles
$Roles = Get-RoleAssignmentPolicy "Default Role Assignment Policy").RoleAssignments
Let's see if this posts properly and preserves formatting.....
Hi, when I enter New-RoleAssignmentPolicy –Name DG-Management –Roles $Roles, I've got the respponse: "New-RoleAssignmentPolicy : A parameter cannot be found that matches parameter name 'Roles'." I need to allow some users to manage a membership for two or three groups. thanks for your answer.
P.S. - I tried it after entering $Roles = (Get-RoleAssignmentPolicy -Identity "Default Role Assignment Policy").AssignedRoles, but $Roles is empty