I had an interesting question the other week about solving a business challenge a customer had with regards to delegating the creation of contact objects in Active Directory.  In their previous messaging system users were managing their own external distribution groups, adding and removing external people, and they wanted to do the same in Exchange 2010. 

A default Exchange 2010 installation does not grant these capabilities by default, so we have to do a little configuration.  Role Based Access Control (RBAC) was introduced by Microsoft in Exchange 2010 and is used to control access to the messaging environment. 

I thought that this would be worth sharing so that the solution is published and the logic of creating the custom RBAC role is discussed. 

Building Blocks

We will need to permit:

• Management of Distribution Groups in Active Directory
• Creation and management of Mail Enabled Contacts in Active Directory
• Management toolset to manage the above

Management of Distribution Groups

Exchange 2010 does not allow a user to manage groups that they own by default.  All of the necessary plumbing is present, you just have to enable the feature.  This is explained in detail here.  Couple of things to note:

• Groups cannot manage groups in Exchange 2010, this feature has returned in Exchange 2013 CU1. There is a workaround for Exchange 2010 
• Make sure the mailboxes and the DGs are in the same GAL

As noted above to manage groups that they own, assign MyDistributionGroups to the appropriate Role Assignment Policy.  In the below example the Default Role Assignment Policy was changed to enable this.  Note that this will allow users to also create new Distribution Groups, so I’ll cover that in a separate blog.  Also you may not want to change the Default Role Assignment Policy in your environment.  You can have multiple Role Assignment Policies and different groups of mailboxes can have a Role Assignment Policy that maps to their business needs. 

Well that’s the easy part done !

So let’s create a RBAC Role, and for the purposes of this test do a direct role assignment to one user account, though this can easily be a group and would be the recommended methodology.

Creation & Management of Mail Enabled Contacts in Active Directory

End users cannot create contacts in AD by default, but we can change the default RBAC to allow this.  The trick is to assign just the minimum permissions possible.  RBAC is aware of the permissions that have been assigned to a person, and will change the display to reflect the assigned permissions.  If you do not have access to do something, then you will not see that option. 

Where to start?  We need to know which role contains the cmdlet that we want to leverage.  In this case we want the New-MailContact cmdlet, and to see in which roles it is present we can use Get-ManagementRole and the –Cmdlet parameter

We can see that the Mail Recipient Creation contains the cmdlet that we need.  It also contains a bunch of other cmdlets that would grant too many capabilities.  A full listing is shown below for reference.

The built-in roles are read only and cannot be changed, so we cannot remove any cmdlets from them.  What we can, and will do, is to create a writable copy and make the necessary changes to our copied Management Role.  

To create a new role called AD-Contact-Editors based off the built-in “Mail Recipient Creation”

Right now, our newly created AD-Contact-Editors role is a mirror copy of the original parent role.  Thus it has all the cmdlets and parameters the parent has.  Now we need to strip all of the unwanted cmdlets from our new role. Ultimately we want to leave in the bare minimum.   

You could strip each cmdlet out one at a time.  For this exercise it will be easier to remove all but one and then add a couple back in.  We cannot remove all of the role entries, which is why we leave one behind.  Let’s leave just Get-MailContact in the role.  To remove the role entries, we shall pass the unwanted cmdlets through to Remove-ManagementRoleEntry.  So all cmdlets that are not Get-MailContact will be removed. 

Top Tip:

Always check the objects that are returned prior to piping to the remove cmdlet.

So in this case we would run

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

Only when we are happy with what is returned should we run:

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

If we check to see what’s now in the AD-Contact-Editors Management Role, it only contains the Get-MailContact cmdlet. 

Let’s add back New-MailContact using New-ManagementRoleEntry

If we try and test this in ECP, we only have the capabilities to manage ourselves at this point so we need to add a couple more cmdlets back in.  We need to add

• Remove-MailContact 
• Get-Recipient
• Set-Recipient

This should give you a management role that looks like this:

In case you are wondering why we have not added Set-MailContact to our custom role, there is a very good reason.  Custom Management Roles can only contain cmdlets and parameters that exist in their parent role.  If you check out the original contents of the custom role there is no Set-MailContact cmdlet in it, thus we can never add it to this role.   

Assign the new role to a user.  User-10 will our fluffy and cute guinea pig. 

To check that the Management Role was correctly assigned, we could run:

Get-ManagementRoleAssignment -Role AD-Contact-Editors

Time to test!

Testing & Validation

Probably the most important portion is testing and validation, and is often overlooked.

Test, test and test like you mean it .  

You can allow your end users to use PowerShell to manage create and edit the contacts, though I suspect the admin assistant that wants to use PowerShell will be few and far between…. 

Chances are they will like the nice graphical ECP interface, so let’s focus on that. 

Bellow is what our test user (user-10) sees in ECP.  Note this is the manage my org view.  All they can see is the External Contacts tab. 

In their Groups ECP view they see:

And they can add the contacts to the DG

Outlook also will show the correct directory information.  This is how Outlook 2010 sees the DG:

Conclusion

RBAC in Exchange 2010 allows for a lot of great customisation to the default built-in roles.  For many customers the default roles will work fine, and if not they can be easily customised. 

For the users that you grant these permissions they will be able to manage/edit/delete all the contacts in the organisation. 

This blog shows the basic framework for editing and customising RBAC.  By following the same process of identifying the role you need to work with, copying it and then customising the copied role you can provide a tailored solution to meet your organisation’s needs. 

Cheers,

Rhoderick