Accessing Exchange Online Objects (without legacy auth) | ENow

Microsoft postponed deprecation of Basic Authentication in Exchange Online for existing tenants. Jaap Wesselius (MVP) wrote about this topic already here and explained what Modern Authentication means and how you can monitor existing usage of legacy auth (which Basic authentication basically is).

Therefore, I don’t have to start from scratch and can concentrate on other topics.

Type of recipients

Exchange Online (EXO) provides several kinds of objects you can interact with:

Most likely there are many LOB applications within your organization, which somehow want to interact with these kinds of objects. Programmatically accessing mailboxes or sending e-mails can be challenging. The following details should help you identify how you can achieve your goal. 

Which protocol is available?

There are two types of protocols available:

-Exchange Web Services (EWS)

-REST APIs (Microsoft Graph)

Which endpoints are available?

Both protocols can be accessed via the following endpoints: https://outlook.office365.com and https://graph.microsoft.com

Note: Make sure you have acquired the correct resource/audience in your OAuth token!

Scoping

Scoping means that the application can interact only with certain objects.

Examples:

What’s the story now?

There are a ton of applications out there, which bring you, as a customer, value. This can be related to monitoring, reporting or just an automation of a workflow.

Now as legacy auth is going to be deprecated, you need to change authentication for these apps. In order to do so, you need to understand the previous mentioned facts about recipients, protocols, endpoints, and scopes as this is crucial for your future solution.

Simple example

Imagine you have a 3^rd party vendor product for reporting purposes, which uses EWS for accessing mailboxes. For authentication, currently Basic authentication is used and, in most cases, ApplicationImpersonation permission is granted for the used service account (let’s use the phrase Alternative Service Account ->ASA).

Solution 1

This solution would have the least administrative effort:

Note: Delegated doesn’t mean you cannot use EWS ApplicationImpersonation! It’s meant in the context of OAuth! Also “Application permissions” are not the same as ApplicationImpersonation!

Note: Here's an example for adding code to acquire an access token with Delegated permissions.

In this example only some code change needs to be performed and an application needs to be registered.

Solution 2

With this solution you would also save a license for the ASA, as you don’t need one. The steps are very similar, but this time you grant different permissions:

Note: Here's an example for adding code to acquire an access token with Application permissions.

Both solutions look similar, but the devil is in the detail!

Assuming solution 2 was implemented and it works, and everybody is happy. Now you receive different requirements:

This app can be used only for a subset of users -> this means it must be scoped.

The issue now is that in combination with the protocol EWS and application permissions, scoping is not possible. EWS scoping works only via RBAC, by assigning ApplicationImpersonation using a recipient scope and this can be achieved only with a recipient. Here you can find documentation about how to configure ApplicationImpersonation.

As you can see, it makes a difference and it might not be as easy as initially thought.

Therefore, I created a matrix and table, which should guide you.

Decision matrix

The following should help you identify what needs to be configured and whether you really need an alternative service account (ASA):

Exchange Web Services

REST APIs

Decision table

MFA exception

Whenever you have an ASA, you must consider that an MFA exception is needed. Otherwise the ASA can’t acquire an access token. This is a security topic and you must think twice about.

Recommendation

In order to reduce costs (the need of an O365 license) and keep things simple, I highly recommend using protocol REST APIs with Application permissions. With this, you won’t need an ASA and there’s no MFA exception, and you can even use a certificate as a client secret.

Conclusion

For those who want some more deep technical examples, please read my article "The End Is Near for Legacy Auth."

I can only recommend that you look into your options and/or get in contact with your vendors in order to make the change. The fact that Microsoft delayed deprecation doesn’t mean you should stop now and check later on this topic!

Some of you may be wondering about administrative access for managing recipients.

I can only encourage you to have a look here:

https://aka.ms/exops-apponly

There is something coming!

Monitor Your Hybrid - Office 365 Environment with ENow

ENow’s Office 365 Monitoring solution is like your own personal outage detector that pertains solely to you environment. ENow’s solution monitors all crucial components including your hybrid servers, the network, and Office 365 from a single pane of glass. Knowing immediately when a problem happens, where the fault lies, and why the issue has occurred, ensures that any outages are detected and solved as quickly as possible.