Basic Authentication and Exchange Online – February 2021 Update

[The_Exchange_Team]

Update: The full timeline for retirement of Basic Authentication in Exchange Online is now published in Basic Authentication Deprecation in Exchange Online – September 2022 Update.

We previously announced we would begin to disable Basic Auth for five Exchange Online protocols in the second half of 2021. Due to the pandemic and the effect it has on priorities and work patterns, we are announcing some important changes to our plan to disable Basic Auth in Exchange Online. Please read this post carefully, as there’s a lot of detail.

The first change is that until further notice, we will not be disabling Basic Auth for any protocols that your tenant is using. When we resume this program, we will provide a minimum of twelve months notice before we block the use of Basic Auth on any protocol being used in your tenant.

We will continue with our plan to disable Basic Auth for protocols that your tenant is not using. Many customers don’t know that unneeded legacy protocols remain enabled in their tenant (Security Defaults takes care of this for newly created tenants now). We plan to disable Basic Auth for these unused protocols to prevent potential mis-use. We will do this based on examining recorded usage of these protocols by your tenant, and we will send Message Center posts providing 30 days notice of the change to your tenant. This work will begin in a few months.

The next change to the previously announced plan is that we are adding MAPI, RPC, and Offline Address Book (OAB) to the protocols included in this effort to further enhance data protection.

As clarified in previous blogs, Outlook depends upon Exchange Web Services (EWS) for core features; therefore, tenants using Basic Auth with Outlook must enable Modern Auth before Basic Auth for EWS is disabled. Outlook uses only one type of authentication for all connections to a mailbox, so including these protocols should not adversely affect you. If EWS has Basic Auth disabled, Outlook won’t use Basic Auth for any of the other protocols or endpoints it needs to access.

At this time, we are not including AutoDiscover, another protocol and endpoint used by Outlook. There are two reasons for this. First, AutoDiscover doesn’t provide access to user data; it only provides a pointer to the endpoint that the client should use to access data. Second, as long as a tenant has some EWS or Exchange ActiveSync (EAS) usage, AutoDiscover is necessary for client configuration. Once Basic Auth is disabled for the vast majority of tenants, we’ll consider disabling Basic Auth for AutoDiscover.

Finally, we are aligning our plans with those for SMTP AUTH. We had previously announced that we would begin to disable SMTP AUTH for newly created tenants (and have already done so), and that we would expand this to disable SMTP AUTH for tenants who do not use it. We are continuing to do that, but we will include SMTP AUTH in all future communications and Message Center posts to make it easier for you to track the overall plan.

In summary, we have postponed disabling Basic Auth for protocols in active use by your tenant until further notice, but we will continue to disable Basic Auth for any protocols you are not currently using. The overall scope of this change now covers EWS, EAS, POP, IMAP, Remote PowerShell, MAPI, RPC, SMTP AUTH and OAB.

How Will I Know When My Tenant Is Affected?

We will publish a major change Message Center post to your tenant 30 days prior to disabling Basic Auth for any protocols in your tenant. Major changes also trigger email notifications. We will also publish a Message Center post when we have made the actual change.

What If My Tenant is Using One of These Protocols?

If your tenant is using any of these protocols in the 30 days prior to us randomly selecting your tenant for potential inclusion, we won’t disable them. Should you find a Message Center post to the contrary, please let us know (details on how to let us know will be in the Message Center post) and we’ll exclude you from the change. You’ll be able to do this right up until we disable these protocols for good (at a future date).

How Do I Know if My Tenant is Currently Using One of the Impacted Protocols?

If you aren’t sure if you are using Basic Auth with any of the impacted protocols you can use the Azure AD Sign-In Logs to look at usage in your tenant. Read more about that here.

What Happens If I Missed the Message Center Post and Need These Protocols Re-Enabled?

We are building the capability to allow you to re-enable the protocols yourself via Support Central in the Microsoft 365 admin center. If you find yourself in this situation, you’ll be able to request help in the Microsoft 365 admin center, and we’ll allow you to re-enable these protocols until we disable them in the future.

How Does This Change Affect Authentication Policies?

The switch we use to disable Basic Auth for unused protocols is not available to tenant admins. You won’t see any changes or additions to your existing authentication policies (if you have any) and our change will take precedence over any policies you might have. We understand this might be a bit confusing, so we wanted to note it here.

We hope this change is good news for those of you who needed more time to complete a transition from Basic Auth.

The Exchange Team

[Andrey_Novikov]

Does delegation already implemented?
Our admins tell us that they cant register Azure app\clientid\secret , because i they do so - our software will get too much access rights for exchange, but we need just several mailboxes.

[ERAUGRAD]

HI Andrey,

ApplicationAccessPolicies solve this problem. We use them and they work really well for most things. 

Mike

[Andrey_Novikov]

And they work for exchange as well? We were told that it is impossible for now to limit access of App to several mailboxes.

[tjmoore]

Application Access Policies work for Exchange Web Services now with Exchange Online / 365, and you can control by restricting to only specific mailboxes, or allow all except specific mailboxes.

However from my investigations I could not see a way to limit access within a mailbox, e.g. if I want to restrict a mailbox to read-only. While there are Mail.Read / Calendar.Read etc permissions, they don't appear to work with EWS. I still needed to grant full_access_as_app permission for my application else EWS wouldn't work at all, but the Application Access Policies then limited access to specific mailboxes, but still full access to those mailboxes.

That's using Application Permissions.

You can use Delegate Permissions, in which case you're signing in as a specific user and permissions are the mailbox permissions for that user I would assume. That requires OAuth with consent screen sign-in, which is no use for the application I'm working on as it's an unattended service application.

[ERAUGRAD]

Yes. They are specific to Exchange Online and work as expected. You can limit to a single mailbox or group. The only hole in the system is that it has to be a Mail Enabled Security Group that you scope to. (Exclude or Include) That prohibits the use of Dynamic Groups. Outside of that, it works great and now even works on EWS (since February.)

Scoping application permissions to specific Exchange Online mailboxes - Microsoft Graph | Microsoft ...

[reevesjeremy]

@Greg Taylor - EXCHANGE  Thunderbird does support OAuth IMAP, but they do it wrong...

1) Their Client ID and Secret are stored in the source code, meaning anyone can impersonate TB using a fraudulent TB app.

2) Their AzureAD Application is configured as a Confidential Client. It should be configured as a Desktop Client.

3) RE: Confidential Client configuration, Conditional Access policies do not work with Thunderbird configured with OAuth2 except for the initial authentication. Therefore admins cannot restrict access once a token is granted. Refresh tokens survive password changes/resets, so no reauthentication prompts. The only way to get a reauthentication is to expire the token.

Suggesting Thunderbird OAuth2 is not a real good solution for Enterprise. I have many Thunderbird users who are HEAVILY invested using Basic Auth IMAP right now. I dread the drop dead date when I have to break the news that they all have to go to OWA or Outlook because TB can't be used.

If you're at all interested, check out Case #s 21139004, 22203592, 120072824001696.  They might all be linked up somewhere. There was collaboration between Exchange Team and AzureAD Team on the matter to come to these conclusions.

Jeremy

[newsjunkie]

Why haven't you found a way to implement oauth for syncing from other mailboxes on Outlook.com instead of removing the ability to collect mail from other inboxes. This is really an unfortunate removal of functionality.

[MrDomaas]

Not to step on anyone's toes, but @The_Exchange_Team, I can highly recommand eM Client as a third party email client if you ever need one.

[MohAbidi]

Does the removal of basic authentication will impact customers who are already set up in 2FA with an app password.

[Greg Taylor - EXCHANGE]

@MohAbidi - yes, it will prevent the use of app passwords. App passwords use Basic Auth. 

[MohAbidi]

Hello @Greg Taylor - EXCHANGE 
Thank you for your response
We have several customers today who have Microsoft Outlook configured with an app password as a result of enabling multi-factor authentication.
After the final deactivation of basic authentication, will these people still have the same errors?
Is there a way to rectify this before the deadline

[kDylanHayes]

@MohAbidi 
To get rid of app password I would first track usage via Azure sign-in logs (filter by legacy client apps and MFA for both interactive and non-interactive). Stopping app password usage is hard as there is no smooth migration. What I would do is to slowly disable legacy authentication (conditional access) or to remove the registered app passwords under the users account (per-user MFA page)

[Marco79]

Good morning,

maybe someone can help me with my concern. If we want to disable basic auth for SMTP, which would require to set the manage security defaults to No. As I understood SMTP works only with this setting. What I did not really find or got a clear statement, what happens after decommission of basic auth for SMTP? Will we still be able to use SMTP with OAuth2.0?

Are there any specific settings required or is SMTP with OAuth2.0 not affected when basic auth is disabled?

I was a bit concerned about this statement here: If your authentication policy disables basic authentication for SMTP, clients cannot use the SMTP AUTH protocol even if you enable the settings outlined in this article. For more information, see Disable Basic authentication in Exchange Online." See https://docs.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/authenticated-client....

Marco

[Greg Taylor - EXCHANGE]

@Marco79  - you are correct that if you want to use basic auth with SMTP you need to disable Security Defaults. 

We are not going to disable basic for SMTP in October. If you want to keep using it, you can. 

If you want to only allow OAuth with SMTP, then you can leave Security Defaults enabled. 

[Marco79]

@Greg Taylor - EXCHANGE Thanks for your response and confirmation! Does this also mean as of today if manage security defaults are set to be active, SMTP must work together with OAuth2.0? So that means:

• security defaults = no then SMTP + basic auth must work
• security defaults = yes then SMTP + OAuth2.0 must work

and this holds true also beyond Oct 2022.

Thanks for you help.

Regards Marco

[Greg Taylor - EXCHANGE]

@Marco79 - correct. though I would change this line a bit:

• security defaults = no then SMTP + basic auth must work

to

• security defaults = no then SMTP + basic auth can work (if enabled)

And yes, this is true beyond Oct 2022. 

[Marco79]

@Greg Taylor - EXCHANGE  Thanks so much for help. Helped to clarify the smtp usage.