Exchange Server uses a permissions model called Role Based Access Control (RBAC) to manage the delegation of permissions for Exchange administrative tasks. RBAC was first introduced in Exchange 2010 and continues to be used in Exchange Server and Exchange Online today. It’s important to understand how RBAC works because it is the mechanism that you use to apply a least-privilege approach to Exchange administrative permissions. RBAC is also how end users are granted permissions to perform tasks such as managing their own distribution groups.
In this tutorial we’ll look at:
- How RBAC works by examining the pre-defined RBAC management roles
- How to configure custom management roles
The Basics of Role Based Access Control
Whether you understand the inner workings of RBAC or not, you’re still making use of it every day when you perform Exchange administrative tasks. That’s because RBAC has a series of pre-defined management role groups, management roles, and management role assignments for a variety of common administrative scenarios.
Management role groups are the security groups in Active Directory. You can see the management role groups that Exchange creates during setup in the Microsoft Exchange Security Groups OU in Active Directory.
Some of those groups should already look familiar to you, such as Organization Management and Recipient Management. Some of the groups in that OU are for other purposes, such as the Exchange Trusted Subsystem group which contains computer accounts for Exchange servers. So if you want to see just the role groups, you can switch to the Exchange Management Shell instead and run the Get-RoleGroup cmdlet.
[PS] C:\>Get-RoleGroup
Name AssignedRoles RoleAssignments
---- ------------- ---------------
Organization Management {MyDiagnostics, MyContactI... {MyDiagnostics-Organizatio...
Public Folder Management {Public Folders, Mail Enab... {Public Folders-Public Fol...
Recipient Management {Move Mailboxes, Message T... {Move Mailboxes-Recipient ...
View-Only Organization Man... {View-Only Configuration, ... {View-Only Configuration-V...
UM Management {UM Prompts, Unified Messa... {UM Prompts-UM Management,...
Help Desk {User Options, View-Only R... {User Options-Help Desk, V...
Records Management {Transport Rules, Audit Lo... {Transport Rules-Records M...
Discovery Management {Mailbox Search, Legal Hold} {Mailbox Search-Discovery ...
Server Management {Monitoring, Exchange Serv... {Monitoring-Server Managem...
Delegated Setup {View-Only Configuration} {View-Only Configuration-D...
Hygiene Management {ApplicationImpersonation,... {ApplicationImpersonation-...
Compliance Management {Data Loss Prevention} {Data Loss Prevention-Comp...
Notice how each role group has one or more assigned roles, which refer to management roles. An example of a management role is Mail Recipients.
[PS] C:\>Get-ManagementRole "Mail Recipients" Name RoleType ---- -------- Mail Recipients MailRecipients
Management roles are collections of management role entries. Management role entries are specific tasks that can be performed by users who are assigned with that particular role. Continuing with the example of the Mail Recipients role, the management role entries can be summarized by looking at the description of the management role.
[PS] C:\>Get-ManagementRole "Mail Recipients" | fl Description This role enables administrators to manage existing mailboxes, mail users, and mail contacts in an organization. This role can't create these recipients. Use MailRecipientCreation roles to create them. This role type doesn't enable you to manage mail-enabled public folders or distribution groups. Use the MailEnabledPublicFolders and DistributionGroup roles to manage these objects. If your organization has a split permissions model where recipient creation and management are performed by different groups, assign the MailRecipientCreation roles to the group that performs recipient creation and the MailRecipients roles to the group that performs recipient management.
So the Mail Recipients role contains a whole bunch of role entries to make that possible. Role entries have a naming convention of “RoleEntry”, so all of the role entries for the Mail Recipients role will be named “Mail RecipientsEntry”. This means that you can see the list of role entries for the Mail Recipients role by running the following command:
[PS] C:\>Get-ManagementRoleEntry "Mail Recipients*" | Select Name
On my system there’s 125 role entries for the Mail Recipients role, so I won’t list them all here. But they basically include all the cmdlets you’d need for that purpose, such as Get-Mailbox, Set-Mailbox, and Enable-Mailbox (for mail-enabling an existing user). However, it is a separate management role called “Mail Recipient Creation” that has the role entries that permit creating entirely new recipients, such as New-Mailbox, New-MailUser, and New-MailContact.
Both the Mail Recipients and Mail Recipient Creation roles, along with others, are assigned to the role group named Recipient Management. You can see the role assignments for the Recipient Management role group by running the Get-RoleGroup cmdlet.
[PS] C:\>Get-RoleGroup "Recipient Management" | Select -ExpandProperty Roles | Select Name Name ---- Move Mailboxes Message Tracking Mail Recipient Creation Mail Recipients Mail Enabled Public Folders Recipient Policies Migration Distribution Groups Team Mailboxes
The Recipient Management role group is one of the Active Directory security groups that exists in the Microsoft Exchange Security Groups OU. Therefore, if you add a user account to the Recipient Management group, they are granted the ability to perform those administration tasks such as managing mail recipients, distribution groups, and performing message tracking. When that user opens the Exchange Management Shell, only the cmdlets that are included in the role entries for the management roles assigned to the role groups they are a member of will be available. For example, a Recipient Management role group member won’t have access to the New-AcceptedDomain or Set-AcceptedDomain cmdlets, but they do have access to the Get-AcceptedDomain cmdlet.
When the user logs into the Exchange Admin Center, they will also see only the sections that they have access to through their role group membership. For example in the screenshot below, the web browser on the left shows the sections visible to a Recipient Management role group member, and the browser on the right shows the sections visible to an Organization Management role group member.
Some of the differences are obvious, for example the Recipient Management role group member can’t see the compliance management section of the Exchange Admin Center. Others are not so obvious at first. Both users can see the mail flow section where things like Accepted Domains are managed. The Recipient Management role group holder can still see that section, because they need to be able to “see” the list of accepted domains in the organization when assigning SMTP addresses to recipients. But they can’t edit any of the accepted domains, nor can they add new ones.
As the final piece of the RBAC picture, there’s also the concept of management role scope. The management roles (such as Mail Recipients) assigned to the pre-canned role groups (such as Recipient Management) have a scope of “Organization”, which effectively means they apply to the entire organization. Management roles can be scoped to more specific area, such as to a single organizational unit in Active Directory.
So to summarize what’s been covered so far, RBAC is made up of:
- Management role entries, which are specific tasks that a user can perform, such as running the Set-Mailbox cmdlet.
- Management roles, which are collections of role entries, such as the Mail Recipients role.
- Management role scope, which defines where in the organization a management role is applicable to, such as the entire organization, a specific server, or a specific organizational unit.
- Management role assignments, which link management roles to role groups.
- Management role groups, which are security groups that users can be added to as members to grant them the permissions to perform administrative tasks.
Once you are comfortable with those basics, you can start looking at creating custom roles.
Creating a Custom RBAC Role
Let’s say that you have a user in the organization who is responsible for managing mail contacts. To provide them with the permissions to perform that task, without any additional effort on your part, you would need to add them to the Recipient Management role group. However, that role group permits them to do much more than just manage the mail contacts they are responsible for, so it doesn’t align with the least privilege approach to security.
The more sensible approach is to create a custom RBAC role and assign it to that user, or to a role group that the user can be made a member of.
The easiest way to create a custom role is by using the Exchange Admin Center. In the permissions section under admin roles, click the icon to create a new role group.
Give the role group a meaningful name, and set the organizational unit that you want to limit the role group to.
Next, click the icon to add a role. In scanning through the list of existing roles (remember, these are collections of role entries), there doesn’t appear to be one already created for managing mail contacts. So a custom role (or two) with the role entries for managing contacts needs to be created. Creating custom roles is easiest when you create the custom role based on an existing role, and then customize it for your needs. In this case, Mail Recipients and Mail Recipient Creation are the two roles to base the new custom roles on.
[PS] C:\>New-ManagementRole -Parent "Mail Recipients" -Name "Custom Role - Mail Contacts" Name RoleType ---- -------- Custom Role - Mail Contacts MailRecipients [PS] C:\>New-ManagementRole -Parent "Mail Recipient Creation" -Name "Custom Role - Mail Contacts Creation" Name RoleType ---- -------- Custom Role - Mail Contacts Creation MailRecipientCreation
The next step is to remove the unwanted role entries from each of the custom roles, so that they’re only left with the capability to manage mail contacts.
[PS] C:\>Get-ManagementRoleEntry "Custom Role - Mail Contacts\*" | Where {$_.Name -notlike "*MailContact"} | Remove-ManagementRoleEntry
[PS] C:\>Get-ManagementRoleEntry "Custom Role - Mail Contacts Creation\*" | Where {$_.Name -notlike "*MailContact"} | Remove-ManagementRoleEntry
So now we’re left with two custom roles called “Custom Role – Mail Contacts” and “Custom Role – Mail Contacts Creation”, each containing only the role entries required for managing contacts.
[PS] C:\>Get-ManagementRoleEntry "Custom Role - Mail Contacts\*"
Name Role Parameters
---- ---- ----------
Disable-MailContact Custom Role - Mail Con... {Confirm, Debug, DomainController, ErrorAction, ErrorVariab...
Enable-MailContact Custom Role - Mail Con... {Alias, Confirm, Debug, DisplayName, DomainController, Erro...
Get-MailContact Custom Role - Mail Con... {Anr, Credential, Debug, DomainController, ErrorAction, Err...
Set-MailContact Custom Role - Mail Con... {AcceptMessagesOnlyFrom, AcceptMessagesOnlyFromDLMembers, A...
[PS] C:\>Get-ManagementRoleEntry "Custom Role - Mail Contacts Creation\*"
Name Role Parameters
---- ---- ----------
Get-MailContact Custom Role - Mail Con... {Anr, Credential, Debug, DomainController, ErrorAction, Err...
New-MailContact Custom Role - Mail Con... {Alias, ArbitrationMailbox, Confirm, Debug, DisplayName, Do...
Remove-MailContact Custom Role - Mail Con... {Confirm, Debug, DomainController, ErrorAction, ErrorVariab...
Back to the Exchange Admin Center, the two custom roles are now visible in the picker to add to the new role group we’re creating. Add the two custom roles, and also add the View-Only Recipients role.
Finally, add the users who will be performing the administrative tasks to the role group as members, and save the new role group.
When the members of the new “Mail Contact Managers” role group log in to the Exchange Admin Center, they’ll be able to see the recipients in the organization (just as they can see them in the global address list via Outlook), and in the Contacts area will be able to create new Mail Contacts. If the role group member shown above tries to create a contact in an OU other than the one their role has been scoped to, they’ll receive an error.
But if they choose the correct OU when creating the contact, they’ll be successful. The same OU restrictions also apply to modifying or deleting contacts.
Summary
In this tutorial I’ve demonstrated how to use pre-defined management roles in Exchange Server to assign RBAC permissions for administrative tasks. I’ve also demonstrated how to create custom roles and role groups to assign limited permissions to users for specific tasks.
I got some errors when using the commands provided, a little bit of back and forth with chatgpt got me to this.
$entries = Get-ManagementRoleEntry “Custom Role – Mail Contacts Creation\*”
$filteredEntries = $entries | Where {$_.Name -notlike “*MailContact”}
$filteredEntries | Format-Table Name, Role, Cmdlet
foreach ($entry in $filteredEntries) {
# Erstellung des vollständigen Identity-Werts
$fullIdentity = “$($entry.Role)\$($entry.Name)”
Write-Host “Versuche, den Eintrag zu entfernen: $fullIdentity”
try {
# Entfernen des Eintrags mit dem korrekt formatierten Identity-Wert und ohne Bestätigungsaufforderung
Remove-ManagementRoleEntry -Identity $fullIdentity -Confirm:$false
} catch {
Write-Host “Fehler beim Entfernen des Eintrags: $fullIdentity”
Write-Host $_
}
}
feel free to use
edit: this is for exchange online / o365
Is an Exchange mailbox required on a domain account to add it to the Organization Management Role ? We are using Exchange 2016
It seems I can add domain user accounts and universal security groups to a role. But I’m wondering if there are any limitations in any of the permissions when there is no mailbox assigned to the account?
Thank,
Bill
Yor admin account will need a mailbox to sign in to the ECP console on Exchange 2016.
You do not need to use the mailbox for mail . You can set the mailbox to reject all mail under: Mailbox features – Message Delivery Restrictions.
I am trying to create exactly this same thing in Office 365 Exchange and run into an issue with running the second removal command. One user posted the same issue but never got a response.
When running
Get-ManagementRoleEntry “Custom Role – Mail Contacts Creation\*” | Where {$_.Name -notlike “*MailContact”} | Remove-ManagementRoleEntry
We get
Cannot process argument transformation on parameter ‘Identity’. Cannot convert value “Custom Role – Mail Contacts
Creation” to type “Microsoft.Exchange.Configuration.Tasks.RoleEntryIdParameter”. Error: “The format of the value you
specified in the Microsoft.Exchange.Configuration.Tasks.RoleEntryIdParameter parameter isn’t valid. Check the value,
and then try again.
Parameter name: identity”
+ CategoryInfo : InvalidData: (Custom Role – Mail Contacts Creation:PSObject) [Remove-ManagementRoleEntry
], ParameterBindin…mationException
+ FullyQualifiedErrorId : ParameterArgumentTransformationError,Remove-ManagementRoleEntry
+ PSComputerName : outlook.office365.com
For some reason when running
Get-ManagementRoleEntry “Custom Role – Mail Contacts\*” | Where {$_.Name -notlike “*MailContact”} | Remove-ManagementRoleEntry
It works fine but only leaves 2 cmdlets in there instead of the 4 you are showing. I basically need working script that enables a user to add and remove mail contacts in the ECP, that’s it.
Excellent article and thank you for posting this. I’m having trouble with the following:
Get-ManagementRoleEntry “CustomBNSKMailContacts\*” | Where {$_.Name -notlike “MailContact”} | Remove-ManagementRoleEntry
The error I get multiple times is:
Cannot process argument transformation on parameter ‘Identity’. Cannot convert value “CustomBNSKMailContacts” to type
“Microsoft.Exchange.Configuration.Tasks.RoleEntryIdParameter”. Error: “The format of the value you specified in the
Microsoft.Exchange.Configuration.Tasks.RoleEntryIdParameter parameter isn’t valid. Check the value, and then try again.
Parameter name: identity”
+ CategoryInfo : InvalidData: (CustomBNSKMailContacts:PSObject) [Remove-ManagementRoleEntry], ParameterBi
ndin…mationException
+ FullyQualifiedErrorId : ParameterArgumentTransformationError,Remove-ManagementRoleEntry
+ PSComputerName : outlook.office365.com
Any ideas?
Thanks in advance –
John
I know I’m a year late, but just in case anyone else comes across this same problem.
The syntax for that command needs to look like the below (using your example):
Get-ManagementRoleEntry “CustomBNSKMailContacts\*” | Where {$_.Name -notlike “MailContact”} | %{Remove-ManagementRoleEntry -Identity “$($_.id)\$($_.name)”}
Not sure if this was an error in the article or an Exchange vs EOL thing, or just something Microsoft have changed since, but hey.
Slight error in your script. Missing an *.
Get-ManagementRoleEntry “CustomBNSKMailContacts\*” | Where {$_.Name -notlike “*MailContact”} | %{Remove-ManagementRoleEntry -Identity “$($_.id)\$($_.name)”}
thx for your post !
Hi Paul, I am a great fan of your articles – you save my a.. many times :). I try to find something, hope can help me with this.
I need to understand what rights or group in RBAC – Exchange 2010 – give rights to user to change user account photo. Thumbnail photo I think is name of attribute.
Is I can see it, it’s possible to possible to limit 2: nd level support to only create/change users is specific OU, is it also possible to limit them to a specified DB? – we have all our users in site-specific databases.
Did this, and works great for write scopes, but why on god’s green earth can’t I seem to find a way to limit read scopes?
Does view only permission group members actually need a account with license on office 365 ?
Thanks Paul,
Very helpful article.
One question – is it possible to create a custom group from blank and only add the permissions you require, or is modification by removal from an existing group the only way?
Thanks,
Andy
Is there any role only can change user mailbox quota?
You can create a custom role for that.
Great writeup,
I’m looking to delegate ONLY certain functions to a specific group at my organization; We want them to be able to modify quotas, mailbox delegates, and e-mail addresses, but you don’t appear to be able to do that without a high level of control (or at least it doesn’t appear in the limited ECP).
Is there a way to give the same “view” as full admins for mailbox objects only?
I don’t understand your question. RBAC lets you control granular admin access all the way down to specific cmdlets and parameters of cmdlets. You can create custom roles to allow as much or as little admin access as necessary.
Dear Paul Cunningham,
There are three OU into exchange 2016. When I user of any OU login in CEP, he can see all recipients of all OU but I want that “A user will only see his own OU recipients login exchange 2016 ecp” is it possible ?
Hi paul,
i want to remove “wipe mobile device” permission from role
My test role doesn’t contains clear-mobiledevice command but i can choose this option.
Which role entry related with wipe mobile device?
Thanks.
My test role entries:
Set-CASMailbox
Get-MobileDevice
New-PartnerApplication
Test-ClientAccessRule
Set-ClientAccessRule
New-ClientAccessRule
Get-CASMailboxPlan
Set-PartnerApplication
Export-AutoDiscoverConfig
Get-ActiveSyncDeviceAccessRule
Get-ActiveSyncDeviceClass
Get-ActiveSyncOrganizationSettings
Get-ClientAccessArray
Get-DomainController
Get-OutlookProvider
Get-RpcClientAccess
New-ActiveSyncDeviceAccessRule
New-OutlookProvider
New-RpcClientAccess
Remove-ClientAccessArray
Remove-OutlookProvider
Remove-RpcClientAccess
Set-ActiveSyncDeviceAccessRule
Set-RpcClientAccess
Write-AdminAuditLog
New-AuthRedirect
Set-AuthRedirect
Remove-AuthRedirect
Get-AuthRedirect
New-ClientAccessArray
New-AuthServer
Remove-AuthServer
Set-AuthServer
Get-PartnerApplication
Set-AuthConfig
Set-ClientAccessArray
Get-ClientAccessRule
Get-CASMailbox
Get-AuthServer
Get-AuthConfig
Set-OutlookProvider
Remove-ClientAccessRule
Get-ActiveSyncDevice
Remove-PartnerApplication
Start-AuditAssistant
Set-UnifiedAuditSetting
Set-SweepRule
Set-MailboxLocation
Remove-SweepRule
Remove-MailboxUserConfiguration
Remove-MailboxLocation
New-SweepRule
Import-RecipientDataProperty
Get-UnifiedAuditSetting
Get-SweepRule
Get-RbacDiagnosticInfo
Get-OnlineMeetingConfiguration
Get-MobileDeviceStatistics
Get-MailboxUserConfiguration
Get-MailboxPreferredLocation
Get-MailboxLocation
Enable-SweepRule
Disable-SweepRule
Add-MailboxLocation
SetUserPhoto
Hi Paul,
i have a little bit extra for you excellent blog post. Thank you so much.
Why this? When you use the role View-Only Recipients, you see to much of ecp functions from exchange. We reduce the view to the most necessary.
New-ManagementRole -Parent “View-Only Recipients” -Name “Custom Role – View-Only Recipients”
Get-ManagementRoleEntry “Custom Role – View-Only Recipients\*” | Where {$_.Name -notlike “*MailContact”} | Remove-ManagementRoleEntry
I have not found a option to add more than one role to the custom view
Add-ManagementRoleEntry “Custom Role – View-Only Recipients\Get-OrganizationalUnit”
Add-ManagementRoleEntry “Custom Role – View-Only Recipients\Get-Recipient”
Add-ManagementRoleEntry “Custom Role – View-Only Recipients\Get-Contact”
Now you have only 4 roles
Get-Contact
Get-OrganizationalUnit
Get-Recipient
Get-MailContact
that is all!
Best
Can you help with my above problem running Exchange 2016? I am unable to set the Write Scope to a specific OU. Please see above comments from me.
Problem was sorted out by upgrading from CU7 to CU8
Not working in Exchange 2016. Getting error when applying the role group to the Contacts OU as write scrope:
“Object class organizationalUnit is not recognized as a valid object class for E-mail recipient objects.”
Can you help?
What command are you running?
I am doing from the ECP. According to your guide, I set the Write Scope to a specific OU where we have got the contacts, and then the ECP throws above error.
The corresponding command would be something like:
New-RoleGroup -Name “Mail Contacts Manager” -RecipientOrganizationalUnitScope Contacts -Roles “Custom – Mail Contacts”, “Custom – Mail Contacts Creation” -Members contactadmin
Are you using the full path to the OU?
Yes. Using the Full path in ECP, it sees the OU, otherwise it would say it does not exist.
Ok. I haven’t seen the issue. Maybe there’s an ambiguous OU name causing problems or something like that. Perhaps running the command in the shell will work better.
I know it has been a while, but I just came across this same error:
“Object class organizationalUnit is not recognized as a valid object class for E-mail recipient objects.”
What I had to do was create it with the Write Scope set to Default, save it, then I could come back and change the write scope to an Organizational Unit.
Hope this helps someone in the future.
Thank you. This worked for me.
Perfect! Worked for me too
Awesome! Worked for me.
From ECP Create the Role with Default Scope. After it is created in 2nd Step Add the required OU. Worked for me .
Hey Poul, wonderfull article and really nicely written.
I have tried deploying this setup in our test/QA enviroments but i run into a error when the user needs to select the ou upon contact creation. I looks to me like there is some role/permission needed, if a user should be granted access to navigate the AD (so they can select the right ou which they are allowed to write to)
When the user tries to browse the AD, they are informed that they do not have permission to browse the ad, and the progress circle just keeps spinning.
Have you seen this problem before?