I have a question and was hoping you’d be able to answer:
We have a vendor that insists on full_access_as_app.

I’ve taken it upon myself to attempt to add lesser permissions, namely Mail.Send, but I don’t think the app is using Graph because the SMTP config screen requires scope (https://outlook.office365.com/.default) and EWS URL (https://outlook.office365.com/EWS/Exchange.asmx). Is my assessment right?

I’ve also set up the Exchange Online Service Principal, Management Scope and assigned the principal to the Application Mail.Send role.

Test-ServicePrincipalAuthorization shows what I expect. Mailboxes in my -RecipientRestrictionFilter are True, and all others are False. When I run Get-MailboxPermission, I can see the object ID of my ApplicationID from Entra in there with full access and NT AUTHORITY\SELF as the user (I assume this is internal to Exchange Online).

However, SMTP test sends still fail though, with a 403 Unauthorized response from Exchange Online. Is there anything else I can try? It seems like we’re at the mercy of the vendor and their code but I’m wondering if I’m perhaps missing permissions. Since the vendor doc only mentions full_access_as_app, and we’re trying to avoid that, it is hard for me to tell what else is needed. Maybe Exchange Online User.Read.All?

No worries. A good example is always a solid starting point to helping people understand how technology works.

I will do my best to continue to throw light into the shadowy parts of Microsoft 365…

Thank you for clarifying ! really enjoy your posts, keep them coming 😊!

If your app only needs to use the permissions supported by RBAC for applications, everything should work as if the app is assigned consented Graph permissions by Entra ID. I certainly haven’t hit any major problems that weren’t due to my own ineptitude.

Okay, that makes sense. Is there any modification then needed within the application code itself or will this just work fine out of the box?

The whole point of RBAC for Applications is that the app secures its permissions through Exchange Online rather than Entra ID. What you’re describing is the classic Entra ID flow to grant an access token with permissions listed in the token claims. When RBAC for applications is used, Exchange recognizes the permission granted to the service principal and allows the app to use that permission (in the example I cited, Calendar.Read). The permission does not appear in the access token because Exchange Online controls the access to the mailboxes. Only specific permissions are available with RBAC for Applications and full_access_as_app is not one of these.

‘ what permissions do you mean?’ I mean the permissions consented in Entra app registration for the given app. If one adds permissions and provides consent, the returned access token in a client credential flow will have them within its claims for example:

“roles”: [
“full_access_as_app”
],

Now the articel states to remove the permission consent in my case for full_access_as_app. How will the returned token satisfy any permissions if they are removed from the app registration?

First, the intention is that you don’t use an all-encompassing permission like EWS.AccessAsApp. Instead, you should use granular, limited permissions to access the information you need. There is no equivalent of the EWS full_access_as_app permission (which Microsoft is seeking to remove ASAP).

The app will only have Graph permissions if they are assigned to the app… what permissions do you mean? Maybe I am not following the question. Perhaps this example of using an app running with a managed identity that uses a limited calendar read permission to access specific mailboxes using RBAC for applications: https://practical365.com/rbac-for-applications-azure-automation/