The content below is taken from the original ( Microsoft Plans to Disable SMTP AUTH in Exchange Online), to continue reading please visit the site. Remember to respect the Author & Copyright.

The Need to Eliminate Basic Authentication (and use MFA)

There are two things certain in Office 365 security. First, multi-factor authentication (MFA) is a very good thing and will block 99.9% of account compromise attacks. Second, basic authentication is an invitation for an attacker to probe for weakly secured accounts using multiple connection protections, including SMTP.

The message about the need to secure accounts with MFA is slowly getting through. Too slowly, but at least we see some progress. Eliminating basic authentication is high on the agenda of the Exchange Online team. They own protocols like IMAP4, POP3, SMTP, and so on. The introduction of protocol authentication policies in 2018 was a good step forward. Tenant administrators can deploy authentication policies to restrict the number of connection protocols that can be used with basic authentication for mailboxes.

Basic Authentication Deprecation for Multiple Connection Protocols

In March 2018, Microsoft flagged the need for tenants to move away from basic authentication by announcing that support for basic authentication for Exchange Web Services will cease on October 13, 2020. This means that anyone using code built with EWS must upgrade to OAuth 2.0 and use that for authentication. EWS has a limited lifespan and it is a good idea at this point to consider moving code to a Graph-based implementation.

Microsoft then increased the pace in September 2019 by announcing that they will turn off basic authentication for Exchange ActiveSync (EAS), POP3, IMAP4 and Remote PowerShell in October 2020. Microsoft has already enabled OAuth (modern) authentication for EAS and is doing so for POP3 and IMAP4 to give tenants a path forward. Those using Remote PowerShell can connect using the Exchange Online Management module, which only supports OAuth and includes both the old (Remote PowerShell) and new (REST-based) cmdlets.

The SMTP Exception

An interesting detail in the announcement was:

“this change does not affect SMTP AUTH – we will continue supporting Basic Authentication for the time being. There is a huge number of devices and appliances that use SMTP for sending mail, and so we’re not including SMTP in this change – though we are working on ways to further secure SMTP AUTH”

This note is a sober realization that many multifunction devices are configured to connect to Exchange Online to send messages via SMTP (authenticated submission) when printing or copying jobs complete or scripts run to report on different operational conditions. Retrofitting devices to use OAuth is a challenging proposition, so Microsoft is choosing to leave the situation as is for SMTP for now.

Disabling SMTP Authenticated Submissions

Two months later, Microsoft shared some extra detail about their direction to control SMTP authenticated submissions at the Microsoft Ignite 2019 conference. Microsoft noted that the ability to disable this feature on a per-user basis via PowerShell and the Office 365 Admin Center (Figure 1) and at the organization level already exists.

To disable SMTP authenticated submissions for all mailboxes in a tenant with PowerShell, run this command:

Get-CasMailbox | ? {$_.SmtpClientAuthenticationDisabled -eq $Null -or $_.SmtpClientAuthenticationDisabled -eq $False }| Set-CasMailbox –SmtpClientAuthenticationDisabled $True

When a mailbox is blocked from SMTP authenticated submissions, it can’t be used to submit email to Exchange Online by running the PowerShell Send-Message cmdlet (using SMTP AUTH client submission). Attempts to send messages by an unauthorized account see this error:

Send-MailMessage : The SMTP server requires a secure connection or the client was not authenticated. The server response was: 5.7.57 SMTP; Client was not authenticated to send anonymous mail during MAIL FROM

As it’s unlikely that any tenant can stop using PowerShell to send email, they should instead seek to minimize the set of mailboxes that can submit email via PowerShell.

Next Step is at Tenant Level

Microsoft also said that:

“…we’re going to better secure this protocol (disable it) by default, first for new organizations onboarding onto Office 365, then later for tenants with no SMTP authenticated submission usage. We also expect in the future to deliver more tools, reports, and optics to help email admins gain better insight into SMTP authenticated submission usage in their organizations.”

This statement underlines the seriousness of Microsoft’s intent to reduce the attack surface available through SMTP. Soon, new Office 365 tenants will not be able to use SMTP authenticated submission for devices or users. Afterwards, Microsoft will move to disable SMTP authenticated submission for tenants that don’t use the feature. Both these steps make sense. After all, if you don’t use something or have never used something, you won’t miss that thing when it is taken away.

Where SMTP Authenticated Submission Might Go in the Future

Microsoft clearly intends that tenants should protect themselves by limiting SMTP authenticated submissions to as small a set of accounts as possible. What Microsoft is not saying (yet) is when they will disable SMTP authenticated submissions across Office 365. In fact, this probably won’t happen because of likely customer pushback. Apart from devices set up to send email, there are too many PowerShell scripts in use that call the Send-Message cmdlet to send email for Microsoft to be able to disable SMTP authenticated submissions completely. At least, not in the short term.

What I think is more likely is that Microsoft will figure out how best to secure SMTP submissions for devices and scripts in a way that’s easy for tenants to adopt. When they do, I expect Microsoft to set a deadline for tenants to upgrade devices and scripts to use whatever the new mechanism is. Hopefully that limit is reasonable enough to give tenants enough time to do the necessary work.

Tenants should understand that Microsoft is moving in this direction to secure tenant data and operations. With that in mind, it’s a good idea to create an inventory of devices and scripts in use today so that tenants know what work might need to be done in the future. Insecure connectivity protocols are on their way out. The only question now is when this will happen.

The post Microsoft Plans to Disable SMTP AUTH in Exchange Online appeared first on Petri.