exchange online role assignments

• Windows Server OS and management

photo-dave - Fotolia

Understanding Exchange Online's Role-Based Access Control model

The role-based access control model manages and evaluates permissions in exchange online. admins can explore the model, create new permissions and customize roles..

• Adam Bertram

Managing permissions in an Exchange Server environment can be complex, and Exchange Online is no different.

Administrators who manage this messaging platform should understand the Role-Based Access Control  model when setting up permissions for end users.

To enable the management of a Role-Based Access Control (RBAC) model in Exchange, we need to import the PowerShell cmdlets on the administrator's computer.

To do this, connect to Exchange Online and import the session with the following script:

$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential (Get-Credential) -Authentication Basic -AllowRedirection

Import-PSSession -Session $Session

This script will request a password before connecting to Exchange; it then will bring in the necessary cmdlets.

The Exchange Online Role-Based Access Control model consists of several different components: Roles, Role Groups, Role Entries and Role Assignments. To begin exploring, run the Get-ManagementRole cmdlet to see what management roles exist in the environment.

The list can get lengthy, which may lead you to believe there are a lot of roles to manage. However, there is also the default Role Groups, as shown below.

That default set of Role Groups comes with every subscription and is a way to aggregate a large, complex set of granular permissions into a more digestible set of descriptively named groups. Role Groups spare the administrator from having to look at detail-level permissions.

Adding people to roles

Assume an employee has moved to the Help Desk department. There is a Role Group called Help Desk, so the administrator needs to add that end user to the Help Desk role. You can check what role memberships the end user has. Because you don't want to see individual roles, just the role groups, run the following script:

Get-ManagementRoleAssigment -RoleAssignee "jnewhire" | Select-Object -unique RoleAssigneeName

This query returns no results; the blank output means that this user has no roles assigned to it. The following command fixes this:

Add-RoleGroupMember -Identity "Help Desk" -Member "jnewhire"

Next, run the previous command again to find the role membership, which now is called Help Desk.

Adding users to roles one at a time can be tedious. An easier way is to build a filter for the Get-User Cmdlet that finds users and adds them, as such:

Get-User -filter {StateOrProvince -eq "CA" -And Department -eq "Support"} | Foreach-Object{Add-RoleGroupMember -Identity "Help Desk" -Member $_.Identity}

The role membership allows you to run a script to see which PowerShell cmdlets and parameters users in the Help Desk role can run. Results show which Management Roles are grouped into the Help Desk Management Role Group.

The Name column is the name of a Role Assignment Entry. To the left of the dash is the Role Name , and the part to the right is the name of the Role Group -- where role is assigned. Running the following command shows which commands each Role Assignment Entry will allow the user to access:

Get-ManagementRoleEntry -Identity "View-Only Recipients\*"

This list can be extensive. To see what roles give access to a specific command, invoke Get-ManagementRoleEntry, as shown below.

Get-ManagementRoleEntry -identity "*\Get-Mailbox"

Custom role assignment

Default Role Groups and Role Assignments within the Role-Based Access Control model work well for a lot of Exchange Online users, but they're not right for every end user. If the business needs something custom, PowerShell is the best bet.

To customize a role using PowerShell, enable customization by running the Enable-OrganizationCustomization cmdletS . To customize the role, run the cmdlet to instruct Exchange Online that you want your own copy.

For example, customization can help if you want to give Help Desk users the ability to see more of the configuration within the Exchange environment . This should help them track down issues faster before they need to escalate tickets to more privileged admins. We can add the View-Only Configuration role to the Help Desk Role Group, and let them see -- but not change -- more settings.

New-ManagementRoleAssignment -SecurityGroup "Help Desk" -Role "View-Only Configuration"

This command lets Help Desk users view the Exchange environment configuration.

Permission options for RBAC

PowerShell in Exchange essential guide

Dig Deeper on Windows Server OS and management

How to enable Active Directory fine-grained password policies

Reveal Windows file server permissions with PowerShell's help

What's new with the EXO v3 module for Exchange admins?

Deploy an information barrier policy for Microsoft Teams

Centralized identity management is vital to the protection of your organization's resources. Do you know how to secure Azure ...

CIOs are taking a hard look at the VMware portfolio as the number of alternatives rises in the hybrid cloud infrastructure market.

Building AI apps in the cloud requires you to pay more attention to your cloud workload management because of how AI impacts ...

While MSI was the preferred method for distributing enterprise applications for decades, the MSIX format promises to improve upon...

IT admins should know that one of the simplest ways to deploy Windows applications across a fleet of managed desktops is with an ...

A custom ISO for Windows 10 can make desktop deployment and installation much simpler. IT allows admins to including applications...

Without a solid connection, remote desktops simply cannot function. When there are remote desktop connection issues, IT ...

With the acquisition of Cameyo, Google puts ChromeOS into consideration in enterprises alongside thin clients, repurposed PCs or ...

VMware EUC users waiting to see where the products would land after Broadcom's divestiture now have some answers.

Life as a LazyAdmin

Assign Exchange Online Admin Role Permission using PowerShell

Assign exchange online permissions using powershell.

You can quickly and easily assign roles to user accounts using Office 365 PowerShell by identifying the user account’s Display Name and the role’s Name.

To start, you first need to establish a session to Office 365 PowerShell, this can be done by a script a created which is published on Microsoft TechNet. Download :

Once the connection to Office 365 PowerShell made, you can move along and determine the current Roles assigned to the user which you want to assign additional permissions.

For the purpose of this post, my user is called Farren and I will first verify which Role groups she is current part of.

First, I will start by running the following cmdlet to connect to Office 365

Once connected I will, run the following cmdlet to get my test user Farren.

Now that I can view my test user in my tenant, let’s move on and list the available Admin Roles which can be assigned to the user.

To get the list of Admin Roles, you can run the following cmdlet.

As you can see there is a few different types of Admin Roles which can be assigned, but for the purpose of the post we are only focusing on Exchange Online Roles.

To continue, I will be assigning the following two Admin Roles to my test user.

• Exchange Service Administrator
• Mailbox Administrator

These roles can be assigned by running the following cmdlet.

Before I wrap it up let’s verify if the user Farren is now part of the Exchange Service Administrator Role group. This can be done by running the following cmdlet.

And finally, to assign multiple roles to multiple user, the following csv example can be used with the following cmdlets.

The csv should look like the below.

Now that the cv has been created, let’s look at the script which needs to be run.

Script file and CSV file can be downloaded here.

CSV:  O365RoleUpdates

Script:  O365RoleUpdateScript

#ThatLazyAdmin

Sharing is caring!

• Exchange Online

Be First to Comment

Leave a reply cancel reply.

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

Save my name, email, and website in this browser for the next time I comment.

Subscribe for Practical 365 updates

Please turn off your ad blocker and refresh the page to subscribe.

You may withdraw your consent at any time. Please visit our Privacy Statement for additional information

Exchange Server

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.

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.

About the Author

Paul Cunningham

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

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?

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 ?

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?

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

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!

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?

Leave a Reply Cancel reply

Latest articles.

Practical PowerShell: Error Handling

When coding in PowerShell, you should anticipate issues. How you deal with these issues is another story. In this episode of Practical PowerShell, we dive into Error Handling.

TEC Tips: Email Protection Basics

Email is a primary target for breaches, making it crucial to have a strong line of defense for your email security. In this blog, we go over some Email Protection basics to help keep your organization safe.

Practical Graph: Microsoft Launches Entra PowerShell Module

On June 27, 2024, Microsoft launched the preview of the Entra PowerShell module. Built on top of the Microsoft Graph PowerShell SDK, the new module helps organizations that still have PowerShell scripts based on the now-deprecated AzureAD and AzureADPreview modules. If you're in that situation, the Entra module might help. But I recommend using the Microsoft Graph PowerShell SDK instead.

Get the Reddit app

A vast community of Microsoft Office365 users that are working together to support the product and others.

Giving 365 Exchange Role assignments

we want one of our user to have access to add and remove people from exchange online Microsoft 365 groups and distribution lists.

we have tried to make a role group in the "365 admin center"'s "roll assignment" exchange part that has "Distribution Groups" and "Mail Recipients", but i can't find if the user that we gave both of those roles has access to them(he is a normal user, no other admin rights) or where he can access those, as he doesn't have access to the admin center.

are we doing the right thing? how can that user access an interface to add people to those groups/lists?

All about Microsoft 365

ExO RBAC improvements #2: Support for administrative units

Administrative units in Azure AD are the rough equivalent of an OU, and have been around for years. They are a cornerstone of Azure AD’s RBAC model, and as such we’ve covered them extensively over the years. As Microsoft is slowly ramping up support for AUs across various workloads and endpoints, their role continues to grow in importance. In this article, we will examine how Exchange Online supports Administrative units and highlight some scenarios they can be useful for.

As Administrative units are an Azure AD concept, their creation and management remains an Azure AD operation (nowadays you can use either the Azure AD blade, PowerShell or the Graph API). In order to facilitate their usage within Exchange however, Microsoft has introduced the Get-AdministrativeUnit cmdlet, which you can use to list all available AUs within the tenant. Here’s an example:

As evident from the output above, the Name (as well as Identity/Id) value for the corresponding object, which is of the Deserialized.Microsoft.Exchange.Data.Directory.SystemConfiguration.ADAdministrativeUnit type, matches its ExternalDirectoryObjectId value. Not much else is revealed even after examining the full set of properties for the object. After all, AUs are simply a container for objects, so you will only ever need their identifier and the list of members. Speaking of which, Exchange Online does not expose any direct cmdlet to list members of an AU, however you can use a -RecipientPreviewFilter query to get the list. As usual, you will need to obtain the DistinguishedName value first, and then pair it with the AdministrativeUnits keyword. Here’s an example:

If we check the AU membership on Azure AD side, we will see the exact same list of members returned. Technically, you can also use the same method to report on membership of AUs with dynamic membership rules. Things of course get more interesting when we have other object types added as members of the AU, as Exchange Online cannot recognize devices and such. And as we’ve discussed in several articles already, even regular “user” objects are not returned by default. Overall, if you want a proper list, it’s best to check on Azure AD side, as the Exchange methods will only return a list of objects supported by Exchange. Then again, those are the objects you will be configuring permissions for, so that’s still a valuable information.

Now that we know how to list AUs in Exchange, as well as their members, how do we go about leveraging them for the purposes of RBAC? Basically, we have two options. The first, and least recommended one, is to create a management scope based on an AdministrativeUnits query, much like in the examples we used above. Here’s an example of how to do that:

The second method, and the one actually recommended by Microsoft, is to leverage the newly introduced -RecipientAdministrativeUnitScope parameter for the New-ManagementRoleAssignment cmdlet. As the name suggests, you can use said parameter to directly scope the newly created management role assignment to just recipients that are members of a given AU, where you can reference the AU in question by its name or objectID (as in, no need to use the DistinguishedName value). At least in theory, as in my tests, using the AU’s display name as input resulted in errors and I had to use the objectID instead. Still, the objectID is easier to handle than the DistinguishedName 🙂

With this information at hand, here’s how to configure an AU-scoped role assignment. In the examples below, we will grant the “User options” management role to a specific user (“gosho”), and scope the management role assignment to just members of the “Bulgaria users” Administrative unit. The following cmdlets can be used:

As detailed in our previous article , you can also use Administrative units to create scoped management role assignments for applications. The syntax is the same, though you will have to use the -App parameter instead of -User , and specify one of the supported SP-assignable management roles. Here’s an example:

To list all existing management role assignments scoped to administrative units, use the -RecipientWriteScope parameter of the Get-ManagementRoleAssignment cmdlet:

The Get-ManagementRoleAssignment cmdlet also supports a -RecipientAdministrativeUnitScope parameter, which in theory should allow us to filter the set of management role assignments by a specific AU. Unfortunately, using the parameter currently seems to always result in an error, regardless of the value provided for the AU identifier. An alternative approach to achieve the same task is to leverage client-side filters, based on the value of the CustomRecipientWriteScope property, which will contain the AU’s identity. Here’s an example:

Note that even though the Get-ManagementRoleAssignment cmdlet supports direct queries based on the CustomRecipientWriteScope value, they also seem to always throw an error, at least currently.

Lastly, if order to test a given AU-scoped management role assignment, all you need to do is login with the corresponding user and try to run one of the allowed cmdlets against an object within the AU scope. Compare the results with running the cmdlet against an object outside of the AU scope and you will know whether the AU-scoped management role assignment works as expected. And for application-based management role assignments, you can leverage the Test-ServicePrincipalAuthorization cmdlet, as detailed in our previous article.

In summary, the Exchange Online RBAC model now has support for scoping management role assignments based on membership of Azure AD administrative units. This is a welcome addition, which brings the ExO and Azure AD RBAC models closer together, and enables additional scenarios. Going forward, customers can use an unified AU-based scoping approach for restricting both Azure AD and Exchange Online operations. That said, good old management scopes in Exchange Online remain supported and can still help you address some corner scenarios, such as where you want to scope the objects based on the value of some Exchange-specific attribute (which is not exposed in Azure AD).

Going forward, we’re likely see administrative units incorporated in the Exchange Admin Center, and hopefully, an UI-based approach for managing (or at the very least viewing) management role assignments. Stay tuned!

1 thought on “ ExO RBAC improvements #2: Support for administrative units ”

• Pingback: A love story about Role Based Access Control for Applications in Exchange Online, Managed Identities, Entra ID Admin Units, and Graph API - JanBakker.tech

Leave a Reply Cancel reply

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

Save my name, email, and website in this browser for the next time I comment.

This site uses Akismet to reduce spam. Learn how your comment data is processed .

This browser is no longer supported.

Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.

Role assignment policies in Exchange Online

• 15 contributors

A role assignment policy is a collection of one or more end-user roles that enable users to manage their mailbox settings and distribution groups in Exchange Online. End-users roles are part of the role based access control (RBAC) permissions model in Exchange Online. You can assign different role assignment policies to different users to allow or prevent specific self-management features in Exchange Online.

In Exchange Online, a default role assignment policy named Default Role Assignment Policy is specified by the mailbox plan that's assigned to users when their account is licensed. For more information about mailbox plans, see Mailbox plans in Exchange Online .

Role assignment policies are how end-user roles (as opposed to management roles) are assigned to users in Exchange Online. There are several ways you can use role assignment policies to assign permissions to users:

New users :

• Change the end-user roles that are assigned to the default role assignment policy.
• Create a custom role assignment policy and set it as the default. Note that this method only affects mailboxes that you create without specifying a role assignment policy or assigning a license (the license specifies the mailbox plan, which specifies the role assignment policy).
• Specify a custom role assignment policy in the mailbox plan. For more information, see Use Exchange Online PowerShell to modify mailbox plans .

Existing users :

• Assign a different license to the user. This will apply the settings of the different mailbox plan, which specifies the role assignment policy to apply.
• Manually assign a custom role assignment policy to mailboxes.

The available end-user roles that you can assign to mailbox plans are described in the following table:

* This feature isn't available in all regions or organizations.

What do you need to know before you begin?

Estimated time to complete each procedure: less than 5 minutes.

The procedures in this topic require the Role Management RBAC role in Exchange Online. Typically, you get this permission via membership in the Organization Management role group. For more information, see Manage role groups in Exchange Online .

To open the Exchange admin center (EAC), see Exchange admin center in Exchange Online . To connect to Exchange Online PowerShell, see Connect to Exchange Online PowerShell .

Changes to permissions take effect after the user logs out and logs in again.

View roles assigned to a role assignment policy

Use the eac to view roles assigned to a role assignment policy.

In the EAC, click Roles > Admin roles . All of the role groups in your organization are listed here.

Select a role group. The details pane shows the Name , Description , and add the Permissions of the role group.

Use Exchange Online PowerShell to view roles assigned to a role assignment policy

To view the roles assigned to a role assignment policy, use the following syntax:

This example returns the roles that are assigned to the policy named Default Role Assignment Policy.

For detailed syntax and parameter information, see Get-ManagementRoleAssignment .

Note : To return a list of all available end-user roles, run the following command:

Add or remove roles from a role assignment policy

Use the eac to add or remove roles from a role assignment policy.

In the policy properties window that opens, do one of the following steps:

To add a role, select the check box next to the role.

To remove a role that's already assigned, clear the check box.

If you select a check box for a role that has child roles, the check boxes for the child roles are also selected. If you clear the check box of the parent role, the check boxes for the child roles are also cleared. You can select a child role by clearing the check box of the parent role and then selecting the individual child role.

When you're finished, click Save .

Use Exchange Online PowerShell to add roles to a role assignment policy

Adding a role to a role assignment policy creates a new role assignment with a unique name that's a combination of the names of the role and the role assignment policy.

To add roles to a role assignment policy, use the following syntax:

This example adds the role MyMailboxDelegation to the role assignment policy named Default Role Assignment Policy.

For detailed syntax and parameter information, see New-ManagementRoleAssignment .

Use Exchange Online PowerShell to remove roles from a role assignment policy

Use the procedure from the Use Exchange Online PowerShell to view roles assigned to a role assignment policy section earlier in this topic to find the name of the role assignment for the role that you want to remove (it's a combination of the names of the role and the role assignment policy).

To remove the role from the role assignment policy, use this syntax:

This example removes the MyDistributionGroups role from the role assignment policy named Default Role Assignment Policy.

For detailed syntax and parameter information, see Remove-ManagementRoleAssignment .

Create role assignment policies

Use the eac to create role assignment policies.

In the EAC, go to Roles > Admin roles and then click Add role group .

In the Add role group window, click Set up the basics section, configure the following settings and click Next :

Name : Enter a unique name for the role group.

Description : Enter an optional description for the role group.

Select the roles that you want to assign to the policy.

In the Add permissions section, select the roles and click Next . Roles define the scope of the tasks that the members assigned to this role group have permission to manage.

In the Assign admins section, select the users to assign to this role group and click Next . They'll have permissions to manage the roles that you assigned.

In the Review role group and finish section, verify all the details, and then click Add role group .

Click Done .

Use Exchange Online PowerShell to create role assignment policies

To create a role assignment policy, use the following syntax:

This example creates a new role assignment policy named Contoso Contractors that include the specified end-user roles.

For detailed syntax and parameter information, see New-RoleAssignmentPolicy .

Modify role assignment policies

You can use the EAC or Exchange PowerShell to Add or remove roles from a role assignment policy .

You can only use Exchange Online PowerShell to specify the default role assignment policy that's applied to new mailboxes that aren't assigned a license or a role assignment policy when they're created.

Otherwise, all you can do in the EAC or Exchange Online PowerShell is modify the name and description of the role assignment policy.

Use Exchange Online PowerShell to specify the default role assignment policy

To specify the default role assignment policy, use the following syntax:

This example configures Contoso Users as the default role assignment policy.

Note : The IsDefault switch is also available on the New-RoleAssignmentPolicy cmdlets.

For detailed syntax and parameter information, see Set-RoleAssignmentPolicy .

Remove role assignment policies

You can't remove the role assignment policy that's currently specified as the default. You first need to specify another role assignment policy as the default before you can delete the policy.

You can't remove a role assignment policy that's assigned to mailboxes. Use the procedures described in the Use Exchange Online PowerShell to modify role assignment policy assignments on mailboxes section to replace the role assignment policy that's assigned to mailboxes.

Use the EAC to remove role assignment policies

In the EAC, go to Roles > Admin roles .

Select the role group and click Delete .

Click Confirm in the confirmation window.

Use Exchange Online PowerShell to remove role assignment policies

To remove a role assignment policy, use the following syntax:

This example removes the role assignment policy named Contoso Managers.

For detailed syntax and parameter information, see Remove-RoleAssignmentPolicy .

View role assignment policy assignments on mailboxes

Use the eac to view role assignment policy assignments on mailboxes.

In the mailbox properties window that opens, click Mailbox features . The role assignment policy is shown in the Role assignment policy field.

Use Exchange Online PowerShell to view role assignment policy assignments on mailboxes

To see the role assignment policy assignment on a specific mailbox, use the following syntax:

This example returns the role assignment policy for the mailbox named Pedro Pizarro.

To return all mailboxes that have a specific role assignment policy assigned, use the following syntax:

This example returns all mailboxes that have the role assignment policy named Contoso Managers assigned.

Modify role assignment policy assignments on mailboxes

A mailbox can have only one role assignment policy assigned. The role assignment policy that you assign to the mailbox will replace the existing role assignment policy that's assigned.

Use the EAC to modify role assignment policy assignments on mailboxes

In the EAC, click Recipients > Mailboxes , and do one of the following steps:

Multiple mailboxes : Select multiple mailboxes of the same type (for example, User ) by selecting a mailbox, holding down the Shift key, and select another mailbox farther down in the list or by holding down the Ctrl key as you select each mailbox. In the details pane (that's now titled Bulk Edit ): click More options > click Update . In the Role Assignment Policy section, select the role assignment policy in the window that appears > click Save .

Use Exchange Online PowerShell to modify role assignment policy assignments on mailboxes

To change the role assignment policy assignment on a specific mailbox, use this syntax:

This example applies the role assignment policy named Contoso Managers to the mailbox named Pedro Pizarro.

To change the assignment for all mailboxes that have a specific role assignment policy assigned, use the following syntax:

This example changes the role assignment policy from Default Role Assignment Policy to Contoso Staff for all mailboxes that currently have Default Role Assignment Policy assigned.

Additional resources

The Daily Show Fan Page

Explore the latest interviews, correspondent coverage, best-of moments and more from The Daily Show.

The Daily Show

S29 E68 • July 8, 2024

Host Jon Stewart returns to his place behind the desk for an unvarnished look at the 2024 election, with expert analysis from the Daily Show news team.

Extended Interviews

The Daily Show Tickets

Attend a Live Taping

Find out how you can see The Daily Show live and in-person as a member of the studio audience.

Best of Jon Stewart

The Weekly Show with Jon Stewart

New Episodes Thursdays

Jon Stewart and special guests tackle complex issues.

Powerful Politicos

The Daily Show Shop

Great Things Are in Store

Become the proud owner of exclusive gear, including clothing, drinkware and must-have accessories.

About The Daily Show

This browser is no longer supported.

Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.

Role Based Access Control for Applications in Exchange Online

• 8 contributors

This article will guide you through using granular and scalable, resource-scoped access control: Role Based Access Control (RBAC) for Applications in Exchange Online.

RBAC for Applications in Exchange Online allows admins to grant permissions to an application that's independently accessing data in Exchange Online. This grant can be paired with a scope of access (resource scope) to specify which mailboxes an app can access. This feature extends the current RBAC model in Exchange Online and it replaces Application Access Policies.

The AutoDiscover service can't be accessed when using RBAC Application roles. If you need to perform AutoDiscover requests against Exchange Online, please utilize Microsoft Entra ID permissions with Application Access Policy to limit mailbox access.

At the core of this system is the management role assignment configuration, which expresses an admin's intent to allow a principal to access data. In this case, allowing an app to perform some role against a set of target resources. For example an admin might configure a room booking system with access to calendar data only in specific regions using a Management Scope . See the diagram below illustrating the role assignment model:

Configuration Instructions

The following steps will guide you to create these Application RBAC assignments:

• Create a new resource scope (optional)
• Create a pointer to a Microsoft Entra service principal
• Select the appropriate application role
• Create a New Role assignment
• Test the New Service principal

Requirements

The Organization Management role group has the delegating role assignment for the new Application RBAC roles. You need to be a member of the Organization Management role group to assign these permissions. Alternatively, you can use Exchange Online RBAC to grant delegating assignments to these application roles as you see fit. In Microsoft Entra ID, you need the Exchange Administrator role to assign these permissions.

Define Resource Scope

• Management Scopes: An Exchange entity that represents a set of mailboxes using a filter expression on the properties of those mailboxes.
• Admin Units: A Microsoft Entra resource that can be a container for other Microsoft Entra resources that contains only users groups, or devices. To know more, see Administrative units in Microsoft Entra ID and Create or delete administrative units .

Management Scopes

Management scopes allow an admin to scope a set of mailboxes based on the properties of these objects. Refer to the Management Scope documentation for add , remove , set . Here's a list of the filterable properties in a Management Scope.

While there is a property called Administrative Units, we recommend you use the native Admin Units parameter on a role assignment to avoid creating a scope as an intermediary pointer object.

Service Principals

Service Principals represent an instance of an application within your tenant. You should consider the Service Principal in Exchange to be a pointer to an existing Service Principal in Microsoft Entra ID. Service Principals can't be created directly using Exchange Online tools. Microsoft Entra tools are used to manage Service Principal registrations within tenants. Exchange prevents the creation of an invalid pointer and reflects any deletions of Service Principals in Microsoft Entra ID automatically.

New Service Principal

The following screenshot will help you find these IDs in Microsoft Entra ID:

Don't use the IDs from the App Registrations page, as it shows different values. The red outlined "Application ID" is the AppID and the "Object ID" is the ServiceID.

You can use another approach to find these IDs using Get-MgServicePrincipal .

Remove Service Principal

Set service principal, application roles.

Application roles are a special type of management role in Exchange Online, which is only assignable to an Application. These roles can be enumerated using Get-ManagementRole .

Role Assignments

Management role assignments tie together a principal, role, and custom resource scope of access. This assignment acts as the permissions assignment for a service principal performing a role across a scope.

New Role Assignment

Set role assignment, remove role assignment.

For removing a role assignment, see remove management assignment .

Testing Authorization

A test cmdlet can be used to simulate the behavior enabled by RBAC assignments for a particular service principal.

This method excludes permissions that might be granted seperately in Microsoft Entra ID.

When testing authorization, you can include an optional resource parameter to evaluate which scoped permissions apply to that target mailbox. InScope will = true or false to represent if, true that permission applies to that mailbox for that service principal, or false that service principal has that permission but not over that particular mailbox. Omitting this flag will result in "Not Run".

Test results always include the allowed resource scope for a particular assigned permission.

Test Service Principal Access

After using Connect-ExchangeOnline in PowerShell, follow these steps:

Example One: Configuring calendar read access for Canadian employees using a management scope

Example two: configuring mail.read for all europe admin unit mailboxes, example three: testing permissions assigned to a service principal, limitations.

• Applications can't become member of a Role Group.
• Application roles can only be assigned to Service Principals.
• Application roles can't be copied or derived.
• Exclusive management scopes don't restrict app access.
• Changes to app permissions are subject to cache maintenance that varies between 30 minutes and 2 hours depending on the app's recent usage. When testing configurations, the test command bypasses this cache. An app with no inbound calls to APIs will have its cache reset in 30 minutes, whereas an actively used app will keep its cache alive for up to 2 hours.

Supported Protocols

Supported application roles.

You might notice these roles represent Microsoft Graph permissions that you can consent elsewhere in the Azure Identity platform. These permissions will have the same effect as those Graph permissions except for these role assignments allowing for granular resource scoped access.

Why does my application still have access to mailboxes that aren't granted using RBAC?

You need to ensure that you've removed the tenant-wide unscoped permissions you assigned in Microsoft Entra ID. The permissions assigned using RBAC act in addition to grants you make in Microsoft Entra ID. Microsoft Entra permissions can only be constrained using Application Access Policies.

How can I view and modify all application permissions in one interface?

To ensure admins have a consolidated view of app permissions, we will be surfacing these permissions granted in Exchange Online in a Microsoft Entra admin experience. This feature is upcoming, stay tuned.

How to migrate from Application Access Policies to RBAC for Applications?

With Application Access Policies, you have a service principal, permissions consent in Azure, and a policy associated with a service principal in Exchange Online. While you can restructure your scoping mechanism in any way that works well for you by using Exchange Management Scopes or Administrative Units, here's some guidance on reusing groups in an App Access Policy as the scope for your RBAC for Applications grant. This process will not result in any interruption of use for your app.

Migration steps:

• Create a new management scope, which points to the scoping group from the Application Access Policy
• Create the service principal pointer object
• Assign the needed permissions to the service principal in Exchange Online with the management scope restriction
• Remove consent to permission in Azure
• Remove the Application Access Policy

When creating the management scope in step #1, you'll use a recipient filter with the filter parameter MemberOfGroup . Here's an example: "MemberOfGroup -eq 'CN=mesga20220818210551,OU=Fabrikam346.onmicrosoft.com,OU=Microsoft Exchange Hosted Organizations,DC=NAMPR00A001,DC=prod,DC=outlook,DC=com'"

This filter parameter uses the distinguished name of the group, which you can find using Get-Group cmdlets.

Limitations:

• Nested group members are considered out of scope. Only direct group membership results in the member being considered in scope for the authorization.
• Microsoft 365 Groups, Mail-Enabled Security Groups, and Distribution Lists are supported.

How does RBAC for Applications work alongside Application Access Policies?

Compatibility with App Access Policy

RBAC for Applications replaces Application Access Policies.

The Authorization interoperability can be described as follows:

Application Access Policies constrain ONLY the permissions assigned in Microsoft Entra ID.

RBAC for Applications offers an alternate expression of authorization with an associated resource scope.

An app can have both Microsoft Entra consented permissions and RBAC assignments. We expect this case when an app has tenant wide Mail.Read and scoped Mail.Send, for example.

Permission consents are additive.

Example One: consents from 2 systems

• An app has Mail.Read in Microsoft Entra ID
• This app is scoped to mail-enabled security group 1 using an Application Access Policy
• The same app has Calendar.Read consented for Management Scope 1 in RBAC for Applications
• Mailbox A is in mail-enabled security group 1
• Mailbox B is in scope for Management Scope 1

MS Graph access to an endpoint requiring both Mail.Read and Calendar.Read for App 1:

• Targeting Mailbox A: fails
• Targeting Mailbox B: fails

This endpoint needs both Mail.Read and Calendar.Read. While the app has these permissions individually against two separate mailboxes, it does not have both permissions against one mailbox.

Example Two: assigning the same permission twice

• This app is scoped to mail-enabled security group 1 using an Application Access policy
• The same app has Mail.Read consented for Management Scope 1 using RBAC for Applications
• Management Scope 1 allows access to every mailbox except Mailbox A (according to some filter like 'Alias -ne mbxa')

MS Graph access to an endpoint requiring Mail.Read for App 1:

• Targeting Mailbox A: allow
• Targeting Mailbox B: allow

While the Mail.Read from Microsoft Entra-only allows access to Mailbox A, the RBAC assignment allows access to everything except A. In effect, this allows access to everything because "A and Not A" means everything.

While we've outlined these edge cases for completeness, we don't expect Application Access Policies to be typically used with RBAC for Applications. Tenant-wide permissions should be assigned in Microsoft Entra ID while resource-scoped permissions should be granted using RBAC for Applications.

How many applications are supported by RBAC for Applications?

You can have up to 10,000 applications per tenant using RBAC for Applications. Please let us know if this limit poses a problem for you. We've built RBAC for Applications in a highly scalable way to accommodate the needs of our largest customers.

Feedback on this feature

Feedback on this feature can be shared with [email protected] .

Additional resources