Home » Exchange Server » Exchange Server Role Based Access Control in Action: Using Management Roles

Exchange Server Role Based Access Control in Action: Using Management Roles

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.

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.

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.

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:

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.

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.

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.

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.

With a slightly different approach you could also create one single custom role containing all of the role entries you need, instead of two custom roles. But this approach of creating custom roles based of existing roles is a nice, easy way to do the task.

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.


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.

Paul is a Microsoft MVP for Office Servers and Services. He works as a consultant, writer, and trainer specializing in Office 365 and Exchange Server. Paul is a co-author of Office 365 for IT Pros and several other books, and is also a Pluralsight author.
Category: Exchange Server

Leave a Reply

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