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.

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:

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

1. Create a new resource scope (optional)
2. Create a pointer to a Microsoft Entra service principal
3. Select the appropriate application role
4. Create a New Role assignment
5. Test the New Service principal

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.

• 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 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.

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-ServicePrincipal -AppId <Client Application ID in AAD> -ObjectId <Service principal object ID in AAD> -DisplayName <name>

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

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

Remove-ServicePrincipal -Identity <ObjectID, AppID, or DisplayName> 

Set-ServicePrincipal -Identity <ObjectID, AppID, or DisplayName > -DisplayName <Updated name>

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.

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-ManagementRoleAssignment [[-Name] <String>] -Role <RoleIdParameter> -App <ObjectID, AppID, or DisplayName> -CustomResourceScope <Management Scope> (or -RecipientAdministrativeUnitScope)

Set-ManagementRoleAssignment [-Identity] <RoleAssignmentIdParameter> -CustomResourceScope <Management Scope> (or -RecipientAdministrativeUnitScope)

For removing a role assignment, see remove management assignment.

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

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-ServicePrincipalAuthorization -Identity <ObjectID, AppID, or DisplayName> [-Resource] <target mailbox>

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

New-ServicePrincipal -AppId 71487acd-ec93-476d-bd0e-6c8b31831053 -ObjectId 6233fba6-0198-4277-892f-9275bf728bcc -DisplayName "example"

DisplayName   ObjectId                              AppId
-----------   ---------                              -----
example       6233fba6-0198-4277-892f-9275bf728bcc   71487acd-ec93-476d-bd0e-6c8b3183105

New-ManagementScope -Name "Canadian employees" -RecipientRestrictionFilter "CustomAttribute1 -eq '012332'"

Name                 ScopeRestrictionType      Exclusive      RecipientRoot          RecipientFilter 
----                 --------------------      ---------      -------------          --------------- 
Canadian employees    RecipientScope            False                                CustomAttribute1 -eq '012332'

New-ManagementRoleAssignment -App 6233fba6-0198-4277-892f-9275bf728bcc -Role "Application Calendars.Read" -CustomResourceScope "Canadian Employees"

Name                      Role                 RoleAssigneeName       RoleAssigneeType        AssignmentMethod
----                      ----                 ----------------       ----------------        ----------------
Application Calendar...   Application Ca...    6233fba6-0198-...      ServicePrincipal        Direct

New-ServicePrincipal -AppId eb19847b-5563-42ea-b719-ea47cb0cf4b3 -ObjectId 59b7c6cb-58d3-4ee8-a409-8c1f9dbb5d36 -DisplayName "example"

DisplayName    ObjectId                                  AppId
-----------    ---------                                  -----
example        59b7c6cb-58d3-4ee8-a409-8c1f9dbb5d36       eb19847b-5563-42ea-b719-ea47cb0cf4b3

New-ManagementRoleAssignment -App 59b7c6cb-58d3-4ee8-a409-8c1f9dbb5d36 -Role "Application Mail.Read" -RecipientAdministrativeUnitScope 4d819ce9-9257-44d7-af20-68a49e6697f4

Name                         Role                RoleAssigneeName         RoleAssigneeType             AssignmentMethod
----                         ----                ----------------          ----------------            ----------------
Application Mail.Rea...      Application Ma...   59b7c6cb-58d3-...         ServicePrincipal            Direct

Test-ServicePrincipalAuthorization -Resource b -Identity "DemoB" | Format-Table

RoleName                      GrantedPermissions          AllowedResourceScope        ScopeType                 InScope 
--------                      ------------------          --------------------        ---------                 ------
Application Mail.Read         Mail.Read                   Scope-MESGaDN                CustomRecipientScope     False 
Application Calendars.Read    Calendars.Read              Scope-DL1                    CustomRecipientScope     False 
Application Contacts.Read     Contacts.Read               Scope-MESGa                  CustomRecipientScope     False 

• 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.

• MS Graph
• EWS

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.

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.

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

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:

1. Create a new management scope, which points to the scoping group from the Application Access Policy
2. Create the service principal pointer object
3. Assign the needed permissions to the service principal in Exchange Online with the management scope restriction
4. Remove consent to permission in Azure
5. 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'"

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.

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 doesn't have both permissions against one mailbox.

Example Two: assigning the same permission twice

• 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 Mail.Read consented for Management Scope 1 using RBAC for Applications
• Mailbox A is in mail-enabled security group 1
• 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.

You can have up to 10,000 applications per tenant using RBAC for Applications. 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.

The AutoDiscover service can't be accessed when using RBAC Application roles due to a bug which is being addressed.

Deleted service principals in Entra are also removed in Exchange automatically. This will delete any assignments made to these service principals but leave management scopes unaffected.

Feedback on this feature can be shared with exoapprbacpreview@microsoft.com.