EWS impersonation in Microsoft Graph: application permissions and mailbox scope
A service that works in many mailboxes used EWS impersonation: one identity, and an ImpersonatedUserId on each call. Microsoft Graph has no such header. The application gets permissions of its own, and the mailbox is part of the address.
The same call in both
In EWS the service says whom it acts as:
service.ImpersonatedUserId = new ImpersonatedUserId(ConnectingIdType.SmtpAddress, "[email protected]");
var inbox = Folder.Bind(service, WellKnownFolderName.Inbox);In Graph the service signs in as an app registration with application permissions, and names the mailbox in the address:
GET https://graph.microsoft.com/v1.0/users/[email protected]/mailFolders/inboxMicrosoft documents the user’s object ID or user principal name for that place in the address. If your code holds SMTP addresses that can differ from the user principal name, look the user up first, for example by filtering /users on proxyAddresses. Shared mailboxes and room mailboxes are users too and are reached the same way.
Application permissions cover every mailbox
A permission such as Mail.ReadWrite, granted to the application in Microsoft Entra ID, applies to all mailboxes in the tenant. The EWS setups it replaces were often narrower: the ApplicationImpersonation role could be assigned with a scope.
Exchange Online has a way to narrow it again, RBAC for Applications. It replaces the older application access policies. The permission is then assigned in Exchange, with a scope, instead of being granted tenant-wide in Entra ID:
New-ServicePrincipal -AppId <application ID> -ObjectId <object ID> -DisplayName "Ticket mail reader"
New-ManagementScope -Name "Support mailboxes" -RecipientRestrictionFilter "CustomAttribute1 -eq 'Support'"
New-ManagementRoleAssignment -App <object ID> -Role "Application Mail.ReadWrite" -CustomResourceScope "Support mailboxes"
Test-ServicePrincipalAuthorization -Identity <object ID> -Resource [email protected]- A permission granted in Entra ID and a scoped assignment in Exchange add up. If
Mail.ReadWritestays granted in Entra ID, the scope limits nothing. Remove the tenant-wide grant when you assign the scoped role. - Both IDs come from the Enterprise applications page in Microsoft Entra admin center. The App registrations page shows a different object ID.
- A change takes between 30 minutes and 2 hours to apply.
Test-ServicePrincipalAuthorizationbypasses that cache, so test with it instead of with the application. - The same mechanism has a role for EWS itself,
Application EWS.AccessAsApp, for as long as the application still calls EWS.
What impersonation did that application permissions do not
- Acting as the user. With impersonation, Exchange checked what the impersonated user was allowed to do. When the service, acting as Ada, opened a folder in Grace’s mailbox, Ada’s rights decided. Graph checks the application’s permissions only, so the application has to make that decision itself.
- Sending as the user. A message sent with application permissions comes from the mailbox in the address. Sending on behalf of another mailbox follows the mailbox permissions in Exchange, and a newly granted right can take a while to reach Graph.
- Identifying users by SID.
ConnectingIdType.SIDhas no counterpart; a SID from on-premises Active Directory can be looked up in the directory throughonPremisesSecurityIdentifier.
An application with a signed-in user
An interactive application that used EWS with the user’s own credentials moves to delegated permissions instead: the user signs in, and Graph applies that user’s rights, including to shared and delegated mailboxes (Mail.ReadWrite.Shared). That is a different design from a background service and needs no RBAC scope.
What Sunsetless EWS does
With Sunsetless EWS the code keeps setting ImpersonatedUserId, by SMTP address, user principal name or SID, and the library puts the mailbox into the Graph address. It signs in as your app registration with a client secret or a certificate. Scoping the application to its mailboxes with RBAC for Applications stays a decision in your tenant. One difference from EWS is listed in the compatibility table: access to a second mailbox is decided by the application’s permissions, and a setting makes the library refuse it the way EWS would without rights.