Eliminating Basic Auth for Exchange Online with AAD Conditional Access Policies

Reducing Account Compromises for Exchange Online

Last October, Microsoft introduced the ability for Office 365 tenants to disable basic authentication for Exchange Online using protocol authentication policies. A recent tweet from Alex Weinart, a Group program manager on the Azure Active Directory team said that disabling basic auth reduces the account compromise rate by 67%. This is more than enough evidence for anyone running an Office 365 tenant to disable basic auth now.

Microsoft says that disabling basic auth reduces account compromise
Microsoft says that disabling basic auth reduces account compromise

Alex’s tweet also pointed to an interesting post called Discovering and Blocking Basic Auth that gave further evidence for the case against basic auth, especially for tenants who still support really old protocols like IMAP4 and POP3.

Why Do People Still Use Old Email Clients?

I don’t quite know why people still use IMAP4 and POP3 clients. Both protocols originate in the early days of email when the world and the internet were safer places and attackers didn’t seek to piggyback on top of protocols with brute-force and password spray attacks.

The simple fact is that more modern and safer email clients are available. Clients that support modern authentication include OWA for browsers and Outlook mobile for Android and iOS. People using Outlook for Windows should be forced to use modern authentication. Apart from personal choice (“I really like using the old Thunderbird client”), no good reason exists to support the use of old and insecure clients. The bottom line is that if you move people to safer clients, you can disable the IMAP4 and POP3 protocols completely to close a big fat hole in your tenant’s defenses.

Exchange Web Services

Although it can also use basic auth, Exchange Web Services (EWS) is in a different category to IMAP4 and POP3. EWS is used by the Outlook for Mac client and it’s also used by backup and migration products to stream Exchange Online data from mailboxes (backup) or import information into mailboxes (migration). It’s also possible that EWS is used by other third-party products. Overall, it’s unlikely that you can block EWS any time soon.

Understand and Manage Connection Protocols

The post about discovering and blocking basic auth makes two excellent points. First, you should understand what protocols are being used to connect to Exchange Online mailboxes in your tenant. If you don’t know who uses what protocols, you won’t be able to plan to manage the phase-out or control of protocols using basic auth.

Second, although all important user accounts should be protected by MFA, Azure Active Directory conditional access policies are a very flexible and convenient way to restrict basic auth connections to the lowest possible set, providing that is, if you’re willing to pay for Azure AD Premium licenses (which also enable other useful features such as Office 365 group expiry and naming policies). As the post reminds us, “Last year, we added the ability to block legacy authentication in conditional access” and goes on to explain a scenario where IMAP4 connections are restricted to specific IP addresses.

Creating an Azure Active Directory conditional access policy to block legacy email protocols
Creating a conditional access policy to block legacy email protocols

The post also points to another article describing how to use conditional access policies to block basic authentication. Given the world of threat that we live in and the number of attacks that flow in a continuous stream against Office 365 tenants, you should at least ask the question if you should deploy such a policy (perhaps even to a select group of users or client platforms) to eliminate or reduce the risk posed by basic authentication in your tenant. It’s the right thing to do.

For more information about identities and authentication in Office 365, read Chapter 3 of the Office 365 for IT Pros eBook.

3 Replies to “Eliminating Basic Auth for Exchange Online with AAD Conditional Access Policies”

  1. Interesting note below by Microsoft. So… as the CA polices are applied after the first factor you can have lockout issues with federateded users. Here I was thinking we no longer need to the Auth polices anymore? Thoughts are both still needed?

    ‘Conditional Access isn’t intended to be an organization’s first line of defense for scenarios like denial-of-service (DoS) attacks, but it can use signals from these events to determine access.’

    1. Yep. CA policies are applied after successful authentication. That’s why blocking basic authentication is so important. If an attacker gets past the authentication hurdle they know their credentials are good – they might be blocked by a CA policy afterwards, but they can work on figuring out how to get around that.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.