Zum Inhalt

App Access Policies vs Role Based Access Control for Apps

I want to compare two ways to authorize applications in Exchange Online: the legacy Application Access Policies and the modern Role-Based Access Control (RBAC) for applications. It explains the core concept, what’s supported, and how to set up and test:

  • Application Access Policies (Restricted App)
  • Role-Based Access Control for Applications (RBAC App)

Which design should I choose? (Concept)

Understanding the concept is key as it changed quite a bit.
If you assign Entra ID app permissions and also use Exchange App RBAC at the same time, you may unintentionally allow too much.

Type Default App4 Restricted App1 RBAC App2 Mixed App5
Concept Allow (consent) Restrict allow Allow specific N/A
Entra API permissions Yes (set it) Yes (set it) No3 Yes (set it)
Exchange ServicePrincipal No (Yes) Yes Yes
AccessPolicy No Yes No Yes
ManagementScope No No Optional Optional
ManagementRoleAssignment No No Yes Yes
Graph Permission All (.default) All (.default) Custom (Scopes) Complicated

What is supported (Limitations)

Watch which permission scopes/roles are actually supported.
Assigning scopes that aren’t supported can lead to unintended access to data.

Permissions Restricted App1 RBAC App2 RBAC Name
Mail.Send Yes Yes Application Mail.Send
SMTP.Send No No N/A
SMTP.SendAsApp 4 No (Yes) N/A
Calendars.Read Yes Yes Application Calendars.Read
Calendars.Read.All No No N/A
Mail.Read Yes Yes Application Mail.Read
Mail.Read.All No No N/A (Delegated)
Mail.Read.Shared No No N/A (Delegated)
Mail.ReadBasic Yes Yes Application Mail.ReadBasic
Mail.ReadBasic.All Yes No N/A
Mail.ReadWrite, Mail.Send No Yes Application Mail Full Access
* (Most Permissions) No Yes Application Exchange Full Access
EWS.AccessAsApp No Yes Application EWS.AccessAsApp
full_access_as_app Limited No N/A (use EWS.AccessAsApp)
IMAP.AccessAsApp No No N/A
More... ... ...

Application Access Policies (Legacy)

Application Access Policies restrict which mailboxes an application can access when the app otherwise has global permissions (Permission in Entra ID). You set a policy, scoped to a distribution group or specific identities, and Exchange verifies the policy during execution to allow or deny access.

Deprecation in progress

Avoid using Application Access Policies when a matching RBAC App permission exists (or as a temporary workaround only). Feature parity is not yet complete.

1
2
3
4
5
6
7
# Set
New-ApplicationAccessPolicy -AppId [ClientID or AppID] -PolicyScopeGroupId [Mailadress or Group] -AccessRight RestrictAccess -Description "Restrict this app to members of distribution group."
New-ApplicationAccessPolicy -AppId [ClientID or AppID] -AccessRight RestrictAccess -PolicyScopeGroupId [GroupObjectId]
# Validate
Get-ApplicationAccessPolicy | Where-Object { $_.AppId -eq "[ClientID or AppID]" } | Format-Table -AutoSize
# Test
Test-ApplicationAccessPolicy -AppId [ClientID or AppID] -Identity "user@domain.com"

Role-Based Access Control for Applications (Modern)

App RBAC grants explicit Exchange roles to an application’s service principal. Instead of granting wide Entra ID permissions, you assign narrowly scoped Exchange application roles (for example, Application Mail.Send) and optionally constrain them with scopes (groups, admin units, attributes).

Recommended, development ongoing

Use RBAC App if you understand the concept. Don’t forget to remove Entra ID app permissions afterwards.

1
2
3
4
Connect-ExchangeOnline
# Get-ServicePrincipal | where_.AppId -eq "[ClientID]"}

New-ServicePrincipal -AppId [ClientID or AppID] -ServiceId [EnterpriseAppObjectID] -DisplayName "[DisplayName]_EXO"
Available Permission 

1
Get-ManagementRole | Where-Object { $_.Name -like "Application*" } | ft Name, Description

Scoping options (filter)

Scopes defines the set of recipients the app role applies to. You can target a group, an administrative unit, or create custom recipient filters (such as by UPN, department, city). Choose the scope that matches your use case.

By group (classic)

ObjectID of the Group

1
2
3
4
# New-ManagementScope > Not needed
New-ManagementRoleAssignment -App [ClientID] -Role "Application Mail.Send" -RecipientGroupScope [GroupObjectID]
#New-ManagementRoleAssignment -App [ClientID] -Role "Application Mail.Read" -RecipientGroupScope [GroupObjectID]
#New-ManagementRoleAssignment -App [ClientID] -Role "Application EWS.AccessAsApp" -RecipientGroupScope [GroupObjectID]

By group (alternative)

DistinguishedName of Group

1
2
# TBD (MemberOf)
# New-ManagementScope -Name:"[ScopeName]" -RecipientRestrictionFilter {MemberOfGroup -eq "$($group.DistinguishedName)"}

By attribute or name (simple)

UPN, RecipientType, Department or City

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
New-ManagementScope -Name "SharedMailboxA" -RecipientRestrictionFilter "UserPrincipalName -eq 'sharedmailbox_a@contoso.com' "
# New-ManagementScope -Name "InformationTechnologyA" -RecipientRestrictionFilter "UserPrincipalName -eq 'it@contoso.com'"
# New-ManagementScope -Name "InformationTechnologyB" -RecipientRestrictionFilter "RecipientTypeDetails -eq 'RoomMailbox'"
# New-ManagementScope -Name "InformationTechnologyC" -RecipientRestrictionFilter "Department -eq 'IT'"
# New-ManagementScope -Name "InformationTechnologyD" -RecipientRestrictionFilter "City -eq 'Zürich'"
## Get-Recipient -RecipientPreviewFilter "UserPrincipalName -eq 'sharedmailbox_a@contoso.com'"

New-ManagementRoleAssignment -App [ClientID] -Role "Application Mail.Send" -CustomResourceScope "SharedMailboxA"
#New-ManagementRoleAssignment -App [ClientID] -Role "Application Mail.Send" -CustomResourceScope "InformationTechnologyA"
#New-ManagementRoleAssignment -App [ClientID] -Role "Application Mail.Send" -CustomResourceScope "InformationTechnologyB"
##New-ManagementRoleAssignment -App [ClientID] -Role "Application Mail.Read" -CustomResourceScope "InformationTechnologyC"

By admin unit (new)

ObjectID of the AdministrativeUnit

Licensing

Administrative units are only available with Microsoft Entra ID P1 or P2

1
2
3
4
5
Get-AdministrativeUnit -Identity [AdminUnitObjectID]
# Get-MgAdministrativeUnit | ft Id, Description, DisplayName
# New-ManagementScope > Not needed
New-ManagementRoleAssignment -App [ClientID] -Role "Application Mail.Send" -RecipientAdministrativeUnitScope [AdminUnitObjectID]
#New-ManagementRoleAssignment -App [ClientID] -Role "Application Mail.Read" -RecipientAdministrativeUnitScope [AdminUnitObjectID]

By GUID (static)

ObjectID of Mailbox

1
2
# TBD (Guid)
# New-ManagementScope -Name "[ScopeName]" -RecipientRestrictionFilter "Guid -eq '43134a98-878a-4c16-b530-000000000000'"

Testing

Validate both the assignments and the effective access. First, list role assignments for the app to confirm roles and scopes. Then use Test-ServicePrincipalAuthorization against specific resources (mailboxes) to verify that the app can or cannot access them as expected.

Propagation delay

RBAC App2: It may take an hour or more for the permission to become active.
Restricted App1: It may take an hour or more for the restriction to become active.

1
2
3
Get-ManagementRoleAssignment | Where-Object { $_.App -eq "[ClientID]"} | ft Identity
Test-ServicePrincipalAuthorization -Identity [ClientID] -Resource "sharedmailbox_a"
Test-ServicePrincipalAuthorization -Identity [ClientID] -Resource "it@contoso.com" | ft

Summary

There are two different Concepts: Restrict Allowed and Allow specific, as seen here:

  • Application Access Policies: restrict allowed targets for a broadly permitted app.
  • App RBAC: allow specific actions on specific resources via Exchange roles.

Prefer App RBAC where possible. If you must mix, be very explicit and verify the effective access.
Wishing you a great day from ESPC in Dublin.

Reference:

  1. Application Access Policies (Restricted App) ↩↩↩

  2. Role Based Access Control for Applications (RBAC App) ↩↩↩

  3. Remove the Entra ID App Permission ↩

  4. SMTP.SendAsApp = New, Rolling out early November 2025 ↩↩

  5. App (AppID) which has both concept in use at the same time ↩

Kommentare