Basic Authentication Deprecation in Exchange Online – Time’s Up

Hello, Like Jesse our Line Of Business (LOB) app using App Password to access Office365 SMTP using simple authentication also got disabled by some policy change by Microsoft some time after 28 Sep 2023.

This is my first post to this community, so please bear with me.

We are the developer of the LOB for a client that do their business in a third party cloud environment (One domain controller, one Terminal Server and another Server with SQL Db backend; they use Office365 administered by the cloud provider).

In early 2022 the client got switched to MFA using DUO whenever accessing remotely their VMs. I believe MFA is also in use on users' outlook accounts.

However we managed to keep App Password for the LOB application.

The App Password authentication to the Office365 SMTP server has been cut off a number of times; never been able to find out who initiated these cut offs - cloud provider or Microsoft. At one time we got word that the reason why the App Password had been turned off was due to many attempts to access the SMTP server from the info@[domainname].org from outside of the domain.

The SMTP authentication has been set up to only accept attempts from within the domain IP address, and so far their cloud provider and tenant administrator has been able to re-instate App Password for the one email account that is used jointly by the LOB for outgoing emails and one Outlook user monitoring incoming emails to the account.

While the cloud provider is trying to solve this latest cut off, I read through the following articles from Microsoft:

1) https://learn.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/authenticated-client-smtp-submission
where I clicked through to this article:
2) https://learn.microsoft.com/en-us/exchange/client-developer/legacy-protocols/how-to-authenticate-an-imap-pop-smtp-application-by-using-oauth
that again on the sidebar had a link to this article:
3) https://learn.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/deprecation-of-basic-authentication-exchange-online?source=recommendations

The second article was one of the sources we used for setting up OAuth2 enhanced authentication with session and refresh tokens back in late 2022 - with assistance from the cloud provider in setting up the parameters in the [domainname].org tenant.

The third article - dated 31 August 2023 - states first up in an 'important' box:
++++++
Basic authentication is now disabled in all tenants.
Before December 31 2022, you could re-enable the affected protocols if users and apps in your tenant couldn't connect. Now no one (you or Microsoft support) can re-enable Basic authentication in your tenant.
Read the rest of this article to fully understand the changes we made and how these changes might affect you.
++++++

I looked into this further and this article from Microsoft describes the issue further:

https://learn.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/authenticated-client-smtp-submission

If I had access to our client's [domain name].org tenant account I could go in and re-enable the SMTP AUTH setting by following this section of the article:
++++
Use the Microsoft 365 admin center to enable or disable SMTP AUTH on specific mailboxes
Open the Microsoft 365 admin center and go to Users > Active users.
Select the user, and in the flyout that appears, click Mail.
In the Email apps section, click Manage email apps.
Verify the Authenticated SMTP setting: unchecked = disabled, checked = enabled.
When you're finished, click Save changes.
++++

This paragraph:
+++
Virtually all modern email clients that connect to Exchange Online mailboxes in Office 365 or Microsoft 365 (for example, Outlook, Outlook on the web, iOS Mail, Outlook for iOS and Android, etc.) don't use SMTP AUTH to send email messages.
+++
appears to be the reason that SMTP AUTH has been turned off in our client's tenant account.

This paragraph sets out the details around this:
+++
SMTP client email submissions (also known as authenticated SMTP submissions or SMTP AUTH) are used in the following scenarios in Office 365 and Microsoft 365:
POP3 and IMAP4 clients. These protocols only allow clients to receive email messages, so they need to use authenticated SMTP to send email messages.
Applications, reporting servers, and multifunction devices that generate and send email messages.
The SMTP AUTH protocol is used for SMTP client email submissions, typically on TCP port 587. SMTP AUTH supports modern authentication (Modern Auth) through OAuth in addition to basic authentication. For more information, see Authenticate an IMAP, POP or SMTP connection using OAuth.
+++

The article is from February 2023 and the claim that SMTP AUTH is accessible through basic authentication is probably not correct any more, for otherwise we would not experience having App Password authentication being disabled.

The article go on to say:
+++
Therefore, we highly recommend that you disable SMTP AUTH in your Exchange Online organization, and enable it only for the accounts (that is, mailboxes) that still require it. There are two settings that can help you do this:
An organization-wide setting to disable (or enable) SMTP AUTH.
A per-mailbox setting that overrides the tenant-wide setting.
Note that these settings only apply to mailboxes that are hosted in Exchange Online (Office 365 or Microsoft 365).

Note

If security defaults is enabled in your organization, SMTP AUTH is already disabled in Exchange Online. For more information, see What are security defaults?.
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.
+++

Be sure I have looked at the "What are security defaults?" link and the "Disable Basic authentication in Exchange Online" link and I am to say it mildly 'lost in the maze'!

Here is finally a question for you:

With Basic Authentication revoked across any tenant organization by Microsoft on 1st October 2023 - (see above: "Now no one (you or Microsoft support) can re-enable Basic authentication in your tenant.") - how in the world can we re-establish the SMTP AUTH protocol for one or more mailboxes that depend on accessing Office365 SMTP server using OAUTH2 with session and refresh tokens. This workflow to connect to the SMTP server was set up following the quidelines in the second article references above and has been working flawlessly as an alternative to the use of simple authentication with App Password.

After October 1st 2023, when we attempt accessing the Office365 SMTP server using OAUTH2 we get this message in the log:
smtpAuthenticate:
smtp_host: smtp.office365.com
smtp_port: 587
smtp_user: info@[domain name withheld].org
smtpAuthenticate:
login_method: XOAUTH2
auth_xoauth2:
username: info@[domain name withheld].org
sendCmdToSmtp:
SmtpCmdSent: {PasswordOrCredentials}
--sendCmdToSmtp
readSmtpResponse:
SmtpCmdResp: 535 5.7.139 Authentication unsuccessful, SmtpClientAuthentication is disabled for the Tenant. Visit https://aka.ms/smtp_auth_disabled for more information. [BN9PR03CA0847.namprd03.prod.outlook.com 2023-10-07T00:28:20.735Z 08DBC64602854611]
--readSmtpResponse
--auth_xoauth2
Failed to login using XOAUTH2 method
--smtpAuthenticate
ConnectionType: SSL/TLS
--smtpAuthenticate

Can anybody help out here with a straight guideline of how to re-establish SMTP AUTH either for one or two mailboxes or organization-wide?

Jesse (and bboxstart and Philip_Beck ) - we've not changed anything and have no plans to disable basic for SMTP if you still want to use it. Perhaps something else changed...? 

Well we got **bleep**ed today, guess we cant scan to e-mail anymore now. Is there some microsoft number I can forward the angry users to? 

What about physical devices such as scanners that need to send email but will never be able to implement OAuth?

It is mentioned that Basic Authentication will not be disabled for SMTP yet. What are the expectations when this also will be disabled for SMTP? I need this information to decide whether we need to re-order our backlog or not (I know that we should have implemented support for OAuth already ;)).

Thanks in advance!

Basic Authentication isn't disabled for my tenant either. I'll send my tenant id to Greg Taylor - EXCHANGE if you want to look into it.

Thanks in advance!

eNet_LLC - if you send me your tenant details I'll confirm for you exactly when you were notified. Have a look in Message Center and just search for the word Basic, that will likely result in some hits. 

I'm pretty sure my tenant got shut off. MS 365 support has been working on this problem for me for 3 days and I just now came across this thread. We have a support ticket app that uses POP or IMAP with SSL or TLS to retrieve ticket emails.  The developer who wrote it has sold it and the new owner is not going to be adding support to it any time soon. So now Microsoft is forcing me to shop for and buy a new product, not to mention the amount of time and money it's going to cost me to setup and customize a new system. I guess the alternative is that I could pay Google to host my ticket system email account instead...

It really irritates me that I have not received any notice in my MS 365 Admin center before this change hit my tenant. And even more so to Google search and find this info since Microsoft 365 Support has not said anything about this potentially being the culprit while they have been trying to figure out why my ticket system has stopped retrieving emails for the last three days.

It's one thing to be able to secure our service account from getting hacked and stop it from sending spam.  I'm sure you have some reason for not allowing clients the ability to use the connectors and IP policies already developed in our MS 365 tenants to secure our ability to use automated scripts to retrieve our emails safely.  Whatever your reasoning was that made you think it was better to turn it off without allowing other secure options, it definitely didn't work out in terms of providing a good working solution to your customers who need it and pay you for it.

Thanks again for turning it off and wasting a bunch of my time and money without posting me any notice in my admin center. If I turn off something that my client's use every day, and I don't tell them it is happening, they stop being my clients and paying my bills really quick.  Something to consider....

bjackson1280 - drop me a private message too, I'll take a look. But for the broader community - the reason the one before hadn't been picked was because of a datacenter location move that was ongoing. Now that's complete the block will happen soon. We are still finding tenants who are not blocked, but as a %, it's very very small at this point.