<img height="1" width="1" src="https://www.facebook.com/tr?id=1529264867168163&amp;ev=PageView &amp;noscript=1">
blog_listing_hero_img.jpg

Accessing Exchange Online Objects (without legacy auth)

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:

-User Mailbox
-Archive Mailbox 
-Shared Mailbox
-Resource Mailbox (e.g.: room mailbox)
-Group Mailbox
-Distribution groups

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) Documentation on Docs
-REST APIs (Microsoft Graph) Documentation on Docs

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:

-Sending e-mails only for a specific mailbox
-Accessing calendars only for a subset of mailboxes

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 3rd 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:

-Register an application in Azure AD
-Grant the respective permissions:
        -“Delegated permissions” EWS.AccessAsUser.All

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!

Screen Shot 2020-05-05 at 11.30.45 AM

-Rewrite the code to acquire an access token and use this for authentication in your EWS requests.

Note: An example for adding code to acquire an access token with Delegated permissions can be found here.

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:

-Register an application in Azure AD
-This time we grant “Application permissions”

Screen Shot 2020-05-05 at 11.30.33 AM

-Rewrite the code to acquire an access token and use this for authentication in your EWS requests.

Note: An example for adding code to acquire an access token with Application permissions can be found here.

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. Documentation about how to configure ApplicationImpersonation can be found here.

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

Screen Shot 2020-05-05 at 11.12.59 AM

REST APIs

Screen Shot 2020-05-05 at 11.12.41 AM

Decision table

Screen Shot 2020-05-05 at 11.30.20 AM

Screen Shot 2020-05-05 at 11.30.02 AM

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 here.

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.

Learn more