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.
Note: Make sure you have acquired the correct resource/audience in your OAuth token!
Scoping means that the application can interact only with certain objects.
-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.
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).
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!
-Rewrite the code to acquire an access token and use this for authentication in your EWS requests.
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.
The following should help you identify what needs to be configured and whether you really need an alternative service account (ASA):
Exchange Web Services
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.
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.
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.
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.