Register service principals in Exchange

Question

I am being asked to setup a mailbox for application access over Oauth. As is typical for these kinds of reqests, the devs don't really know what they want and just ask support to provide the info (such as shared id/certificate, APP id etc)
I've created a number of these now with Graph application permissions like " Mail.Read" (Read mail in all mailboxes) etc. I've also seen it done with EWS Graph API permissions. I've also then used 'New-ApplicationAccessPolicy' in EXO PS to limit access to the mailbox own account per:

https://learn.microsoft.com/en-us/graph/auth-limit-mailbox-access

I'm becoming increasinly uncomfortable with the seemingly excessive permissions granted to these Service Principles though. Do they really need APPLICATION permissions, which always seem to give everyone access to everything?.

I'm also unclear on when to use 'New-ApplicationAccessPolicy' to limit access, or when one should Register service principals in Exchange per:

https://learn.microsoft.com/en-us/exchange/client-developer/legacy-protocols/how-to-authenticate-an-imap-pop-smtp-application-by-using-oauth

Which invokes these PS functions:

a. New-ServicePrincipal -AppId

Answer 1

Hi Bob, So there are really a few things here:

The Service Principal requirement with full mailbox access: That is for IMAP, POP and SMTP perms right now:

https://learn.microsoft.com/en-us/exchange/client-developer/legacy-protocols/how-to-authenticate-an-imap-pop-smtp-application-by-using-oauth#use-client-credentials-grant-flow-to-authenticate-smtp-imap-and-pop-connections

The other graph Exchange perms allow you to leverage the access policy ( or the newer RBAC )

https://learn.microsoft.com/en-us/exchange/permissions-exo/application-rbac

Both of these methods allow applications to access an Exchange mailbox while at the same time limit its access based on the settings ( or in the case of the Service Principal using Oauth, POP and SMTP - the mailbox you have given full access to)

For an application that has no signed in user, you have to provide application access otherwise it wont work ( versus delegated) , however the limits you have set via the application access policy or RBAC perms ensure the application cant access all the mailboxes, just the ones you have allowed it to.

So to answer your specific question. If the perms requested are:

For POP access, choose the POP.AccessAsApp permission. For IMAP access, choose the IMAP.AccessAsApp permission. For SMTP access, choose the SMTP.SendAsApp permission.

then follow that Oauth Doc and create the Service Principal in Exchange and give it full access to that mailbox.

If the perms needed by the app are the following:

https://learn.microsoft.com/en-us/exchange/permissions-exo/application-rbac#supported-application-roles

and you are using the new RBAC method, then follow that doc and create the Service principal and assign the perms.

If however, you are still using the original application access policies, then no need to create the service principal.

https://learn.microsoft.com/en-us/graph/auth-limit-mailbox-access

I think you can see where this is going however. In the future, Exchange Access via graph will leverage service principals and the old access policies will be removed, so its prob worth it now to get started with the new RBAC methods.

As far as using a shared mailbox, yes you can, if the app supports it. I have a few that do this and its always nice when it does, but I can't tell you if yours will or not, worth testing!