0

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:

Exchange 2010 RBAC - Management Role Entries In Custom Role AD-Contact-Editors

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.

Exchange 2010 RBAC - ECP View Of Custom Role AD-Contact-Editors

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

Exchange 2010 RBAC - Checking To See Where Cmdlet Exists

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"

Exchange RBAC - Creating Custom Management Role

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.

Exchange RBAC - Removing Unnecessary Cmdlets From Custom Management Role

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*

Exchange RBAC - Checking Cmdlets Present In Custom Management Role

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:

Exchange RBAC - Adding Back Reqired Cmdlets

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

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

Exchange RBAC - Checking Cmdlets Present In Custom Role

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

Exchange RBAC - Assigning Custom Role Directly To End User

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"

Exchange RBAC - Assigning Custom Role To A Role Group

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

Adding Test Account To Role Group

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:

Exchange RBAC - Able To Edit Properties Of AD Contacts Via ECP

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

Exchange RBAC - Editing AD Contact Via ECP

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

Changes Submitted Via ECP Visible In AD       image

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:

Exchange Custom RBAC Role Assignments

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 Smile

Rhoderick Milne [MSFT]

Leave a Reply

Your email address will not be published. Required fields are marked *