Creating RBAC Role To Delegate Editing Contacts

Previously we discussed how to customise Exchange 2010 RBAC to delegate creating mail enabled contacts.  The intent of that original post was to allow for the for creation of simple mail enabled contacts that would facilitate sharing the SMTP address of a person outside the Exchange organisation.

Marc commented on that post as the provided solution did not fit his requirements which were different.  There was no intent to go and modify the details of the contact objects in the original post.  Phone number, office and location amongst others were not required.  Marc on the other hand does want these fields to be edited.  So what to do?  Time for some more RBAC fun!!!

Reviewing Initial State

Let’s assume that we are at the end state of the previous blog, all those steps were followed and the custom RBAC role of “AD-Contact-Editors” exists as documented in that post.  This would involve running the following PowerShell commands:

New-ManagementRole -Name AD-Contact-Editors -Parent "Mail Recipient Creation"

Get-ManagementRoleEntry -Identity AD-Contact-Editors* | Where-Object {$_.Name -ne 'Get-MailContact'} | Remove-ManagementRoleEntry

Add-ManagementRoleEntry -Identity "AD-Contact-EditorsNew-MailContact"

Add-ManagementRoleEntry -Identity "AD-Contact-EditorsRemove-MailContact"

Add-ManagementRoleEntry -Identity "AD-Contact-EditorsGet-Recipient"

Add-ManagementRoleEntry -Identity "AD-Contact-EditorsSet-Recipient"

New-ManagementRoleAssignment -Role AD-Contact-Editors -User User-1

They should all be on a single line, but may wrap.

Note that the Management Role has been assigned to an individual account – please see the note below on assigning to a group for production usage.

The AD-Contact-Editors custom management role should contain the following cmdlets:

Opening up ECP shows that User-1, who is assigned this custom RBAC role, can Create and Delete contacts.  Note that there is no details button, thus a contact cannot be edited once created, and additionally the capability to edit other properties of the contact are not exposed.

As mentioned in the other post, AD-Contact-Editors is a copy from the built in “Mail Recipient Creation” role since that was the only role which has the New-MailContact cmdlet.  However, it does not contain the Set-MailContact cmdlet, and since the cmdlet does not exist in the parent role it can never be added to the child role.  So if we want to provide the capability to run Set-MailContact then we will need to do some more delegation work in RBAC!

Set-MailContact, Where Art Thee?

As before, lets see where the Set-MailContact cmdlet lives:

Get-ManagementRole –Cmdlet Set-MailContact

We can see that Set-MailContact lives in three places.  In this case we want to leverage the Mail Recipients built in role, so we shall make a copy of that to work with!   For lack of imagination, this new custom role will be called:    AD-Contact-Editors-Recipients. 

Creating Custom Management Role

Lets create the role, by copying the parent role:

New-ManagementRole -Name AD-Contact-Editors-Recipients -Parent "Mail Recipients"

The Mail Recipients role contains a lot of unwanted cmdlets for this task, and since AD-Contact-Editors-Recipients is a direct copy then it too will contain the same unwanted cmdlets.  Lets flush out all cmdlets apart from Get-MailContact.

Get-ManagementRoleEntry -Identity AD-Contact-Editors-Recipients* | Where-Object {$_.Name -ne 'Get-MailContact'} | Remove-ManagementRoleEntry

The above should be on one line, but may wrap.

After pressing “A” to accept that all the cmdlets will be removed, lets check the current contents of our custom AD-Contact-Editors-Recipients role:

Get-ManagementRoleEntry -Identity AD-Contact-Editors-Recipients*

That looks good!  It only contains the Get-MailContact cmdlet – all the others were removed.  Now we can add back in the couple of cmdlets that we need by running all of these commands:

Add-ManagementRoleEntry -Identity "AD-Contact-Editors-RecipientsSet-MailContact"

Add-ManagementRoleEntry -Identity "AD-Contact-Editors-RecipientsEnable-MailContact"

Add-ManagementRoleEntry -Identity "AD-Contact-Editors-RecipientsDisable-MailContact"

Add-ManagementRoleEntry -Identity "AD-Contact-Editors-RecipientsSet-Contact"

Add-ManagementRoleEntry -Identity "AD-Contact-Editors-RecipientsGet-Contact"

I won’t screenshot you to death, so here is just one image showing the above being added back in:

Again, lets check to see the cmdlets contained within the Role:

Get-ManagementRoleEntry -Identity AD-Contact-Editors-Recipients*

Looking good!

Update 1-6-2014:  The focus of the post was on the above items, since creating the custom RBAC role is the hardest part of the process.  Initially this role was directly assigned to an end user called “User-1”, but have also added the steps so that the role assignment has also been done to a Role Group as well.  Thanks for the feedback folks!  For testing purposes individual assignment is fine, though in production usage groups will be used.  Just the same as for NTFS permission assignment….

If you want  to assign directly to an individual account, then execute the:

New-ManagementRoleAssignment -Role AD-Contact-Editors-Recipients -User User-1

Alternatively if you want to assign to a brand new  Role Group called “AD-Contact-Editors-RG” then execute:

New-RoleGroup AD-Contact-Editors-RG -Description "Contact Creators" -Roles "AD-Contact-Editors-Recipients"

If assigning the management Role to a group, we also need to ensure that the test account is added to the Role Group:

Add-RoleGroupMember -Identity AD-Contact-Editors-RG -Member User-1

And then we can run Get-RoleGroupMember to verify the membership addition.

Get-RoleGroupMember -Identity AD-Contact-Editors-RG

Moving on now to the most important part, testing!

Testing & Validation

Logging onto ECP as the test account (User-1), now shows that the details button has been enabled when looking at the contact objects:

We can edit the contact, and fill in some meaningless data!

Once the changes have been saved,  AD users and computers then displays the updated fields:

      

Parting Glass

Since our test user now has RBAC Role Assignments to both the AD-Contact-Editors and AD-Contact-Editors-Recipients custom roles, they are now able to create, delete and modify contact objects!  The two RBAC Role Assignments can be seen below:

To summarise the commands used:

New-ManagementRole -Name AD-Contact-Editors-Recipients -Parent "Mail Recipients"

Get-ManagementRoleEntry -Identity AD-Contact-Editors-Recipients* | Where-Object {$_.Name -ne 'Get-MailContact'} | Remove-ManagementRoleEntry

Add-ManagementRoleEntry -Identity "AD-Contact-Editors-RecipientsSet-MailContact"

Add-ManagementRoleEntry -Identity "AD-Contact-Editors-RecipientsEnable-MailContact"

Add-ManagementRoleEntry -Identity "AD-Contact-Editors-RecipientsDisable-MailContact"

Add-ManagementRoleEntry -Identity "AD-Contact-Editors-RecipientsSet-Contact"

Add-ManagementRoleEntry -Identity "AD-Contact-Editors-RecipientsGet-Contact"

New-ManagementRoleAssignment -Role AD-Contact-Editors-Recipients -User User-1

.

If needed we could have scoped RBAC down even further and limited the actual contact fields they were allowed to modify.  Maybe that’s a post for another day!

Cheers,

Rhoderick

* – The super eagle eyed out there may notice the deliberate image issue above