ApplicationAccessPolicy for EWS

I’m really excited about the fact that Microsoft fulfilled the ask for supporting Exchange Web Services (EWS) protocol in ApplicationAccessPolicy as announced here:

https://techcommunity.microsoft.com/t5/exchange-team-blog/application-access-policy-support-in-ews/ba-p/2110361

Unfortunately Microsoft seems to make it harder for you to add EWS permission full_access_as_app to your app.

It’s gone!

When I heard about this, I was curious about and wanted to cross-check whether it was already available in our tenant or not. Sometimes it takes some more time, until a rollout is complete.

But when I tried to add EWS application permissions to one of my apps, I couldn’t find Office 365 Exchange Online permissions at all. Just to make sure it’s not only my tenant, I checked others and also with different browsers.

All tests with same result:

No Office 365 Exchange Online could be found.

How to add Office 365 Exchange Online permissions to your app

But soon I found out how to add these permissions and thought documenting this might save someone’s time. Here the steps:

  • in the dialog after you clicked “Add a permission”, choose “APIs my organization uses”
  • you will be shown a list with apps. Search for one of the following strings:
    • office 365 exchange
    • 00000002-0000-0ff1-ce00-000000000000
  • now you should see in the result Office 365 Exchange Online
  • pick you permissions (Delegated or Application) and configure your application

Conclusion

I don’t know why the decision was made to remove these permissions from the first tab. Looking at the resource/audience I could recognize one interesting change:

The value changed from outlook.office365.com to ps.outlook.com!

I hope this helps some of you.

2 thoughts on “ApplicationAccessPolicy for EWS

  1. Have been reading through a lot of you blog posts and they have been really helpful. As mentioned in TechNet article, EWS can leverage ApplicationAccessPolicy for accounts with their own “identity” . Could this scoping logic be applied to “traditional” delegated account permission that requires Oauth? (i.e. a ticket system service mailbox that currently logs in using basic auth so it can send/receive mail)
    It should be converted to modern auth but only have permissions to it’s own mailbox and no one else. Any suggestions?

    Like

    • Hi Jon,
      “traditional” delegated permissions like FullAccess to the mailbox is not affected by this, just using OAuth2.0. Just replace Basic with modern auth and nothing will change in a delegated scenario. It highly depends on the vendors implementation as when you use something like a service account it’s usually interactive. This makes it hard to automate things. Many use a service account and leverage the returned refresh token in order to acquire a new access token after expiration (after 1 hour).
      But these policies should not be used for such a scenario.
      Ciao,
      Ingo

      Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s