In June 2010, I wrote an article explaining how Exchange Role Based Access Control (RBAC) works - a new feature released with Exchange 2010. RBAC is still heavily utilised today with Exchange 2019 and Office 365 following these principals.
My article from 2010 can be found here:
https://clintboessen.blogspot.com/2010/06/exchange-2010-role-based-access-control.html
After having not worked with RBAC for while, I found myself re-reading the principals of RBAC and re-running through what is involved to configure the security model. Knowing this well is also essential and I'm doing my Exchange upgrade exam this Friday (MS-202 Microsoft 365 Messaging Administrator Certification Transition) so a refresher on these principals is always handy!
I had a requirement given to me by a customer which I need to spin up in my test lab, and I thought whilst I lab the requirement it might be a good idea to write a quick blog post on the process of implementing the RBAC changes.
RBAC Requirement
"A user in the business must be able to create mail enabled contacts for external workers. This user must only be able to create mail enabled contacts and no other objects, and the contacts must be stored under a specific organisational unit only".
RBAC Security Model
With the design of RBAC, The Exchange Product Team referred to RBAC as the Triangle of Power. This is elaborated in this blog post here:
https://techcommunity.microsoft.com/t5/Exchange-Team-Blog/RBAC-and-the-Triangle-of-Power/ba-p/597147
The security model has three arms:
- Step 1: Where - Where are the objects stored that we want to change or what attributes or identifying factors must the object have? They can be in a security group, organisational unit, anyone with a job title set to XYZ... the possibilities are endless. My requirement for "Where" is contacts must be contained only under a particular organisational unit.
- Step 2: What - What is what you want to do. What Exchange PowerShell cmdlets do you want to give the administrator access to be able to run? Think of "What" as the access rights you wish to delegate. The commands we are interested in for my example are New-MailContact and Remove-MailContact.
- Step 3: Who refers to who is able to perform the operation. Which user do you want to delegate control to in order to run the commands under the What section.
This all glued together by a concept known as Management Role Assignments.
I will break this down using my three headers listed above.
Step 1: Where
In my lab environment we only want contact objects to be changed under the OU "Contacts".
avantlab.local/Contacts
As a result we are going to create a new "Management Scope". By default all RBAC Management Roles have access to the entire Active Directory forest and no Management Scopes exist.
I'm locking it down to the Organisational Unit based on a RecipientRestrictionFilter with the following query:
New-ManagementScope "AvantLab Contacts" -RecipientRestrictionFilter {DistinguishedName -Like '*,OU=Contacts,DC=Avantlab,DC=Local"}
Step 2: What
Now we are interested in assigning "What" cmdlets we want the admin to be able to run. The "What" refers to two cmdlets:
- New-MailContact
- Remove-MailContact
Cmdlets are linked as "ManagementRoleEntries" to objects known as "ManagementRoles".
There are a few rules you need to understand when creating new Management Roles for the "what section":
- It is not possible to simply create a new Management Role and add the cmdlets you wish to run under the role as Management Role Entries. All custom (non default) Management Roles must be linked to a parent Management Role. Parent Management Roles are ones that come by default with Microsoft Exchange Server "out of the box". Think of it as your "cloning" the parent Management Role to create your "Custom" management role.
- It is not possible to add additional cmdlets that were not in the parent - you can however remove cmdlets.
Base on these two rules, when your creating a new Management role your essentially taking a management role similar to what your trying to create "with too much access", and removing the additional access from the role.
So the first step I need to do is find an existing Management Role that contains the two cmdlets I'm interested in. I did this by running the following cmdlets:
Get-ManagementRole -Cmdlet New-MailContact
Get-ManagementRole -Cmdlet Remove-MailContact
A Management Role that contains both these cmdlets is "Mail Recipient Creation" - so this is the Management Role we will use as the template for creating my new Management Role.
I'm calling my new Management Role "Contact Management" and I'm basing it on "Mail Recipient Creation". As a result, the new Management Role was created with the following cmdlet:
New-ManagementRole -Name "Contact Management" -Parent "Mail Recipient Creation"
Now the default "Mail Recipient Creation" Management Role had more cmdlets then we want the delegated access users to have access to. To list all the cmdlets that this Management Role can run, execute the following command:
Get-ManagementRoleEntry "Contact Management\*"
We want to remove all cmdlets not related to our Contact Management. Most importantly we want to remove any cmdlets with "New-, Set-, Start-, Remove-, Disable-, Write-, or Remote-" as they have elevated access. "Get-" cmdlets you cant make changes, you can only view data.
To remove the unwanted cmdlets from the Contact Management Management Role the following cmdlet was used:
Get-ManagementRoleEntry "Contact Management\*" | where {$_.name -eq "New-MailUser"} | Remove-MagementRoleEntry
And a few Get- commands I wanted removed:
This left the Contact Management role with the following cmdlets associated:
Get-ManagementRoleEntry "Contact Management\*"
This left Management Role access to run the following cmdlets. The "Get-" commands present cannot make any changes or expose any information that I would not want the delegated user to see. As a result I didn't clean these up but you can if you want. Most importantly, the New-MailContact and Remove-MailContact cmdlets were left present.
Step 3: Who
The last step is the "delegation of control", which staff members will have access to be able to run the Cmdlets in the Management Role "Contact Management".
To determine the "Who" I created a new Role Group called "Contact Management Admins" defining the "Contact Management" Management Role and the "AvantLab Contacts" Management Scope. This was done with the following command:
New-RoleGroup "Contact Management Admins" -Role "Contact Management" -CustomRecipientWriteScope "AvantLab Contacts"
This creates a new Group under Microsoft Exchange Security Groups in Active Directory for the new Role Group.
Testing the RBAC Security
I went and added a user called DelegationUser to the Contact Management Admins group.
Logging into Exchange Control Panel (now known as Exchange Admin Centre (EAC) in later revisions of the product), the webpage only renders the areas of EAC the user has access to. RBAC and being "Cloud Friendly" are the two primary reasons the old Exchange Management Console from Exchange 2007/2010 was retired.
The user can successfully run the New-MailContact command via the webpage and place a Contact object under the Contacts OU - the Step 1: Where? section.
This is shown in the following screenshot:
However if I try and create a contact in the default Users container, I get the message:
'avantlab.local/Users/DefaultUser Container' isn't within your current write scopes. Can't perform safe operation.
This is because Step 1 "Where"... the management scope is restricted to only the Contacts OU. Obviously Management Scopes are ridiculously granular and you can go far beyond restrictions of something as basic as an OU.
What about the Glue?
Stop sniffing the glue Clint, I thought there was Glue in between holding these objects together as shown in the diagram below.
When I created the Role Group I also specified the Management Role and Management Scope. This automatically created a ManagementRoleAssignment called "Contact Management-Contact Management Admins" as shown in the screenshot below.
Creating ManagementRoleAssignments manually useful especially when you want to create associations between existing objects that already exist on the system.
If we look at the Management Role Assignment "i.e. the glue" closer, we can see that it has all three components created above are "glued" together.
- The Management Scope... Step 1: Where (CustomRecipientWriteScope: AvantLab Contacts)
- The Management Role... Step 2: What (Role: Contact Management)
- The Role Group... Step 3: Who (RoleAssigneeName: Contact Management Admins)
Hopefully this step by step guide to using Role Based Access Control was useful and can be put to use within your environment!
