Block legacy authentication with Microsoft Entra Conditional Access

  • Article

To give your users easy access to your cloud apps, Microsoft Entra ID supports a broad variety of authentication protocols including legacy authentication. However, legacy authentication doesn't support things like multifactor authentication (MFA). MFA is a common requirement to improve security posture in organizations.

Based on Microsoft's analysis more than 97 percent of credential stuffing attacks use legacy authentication and more than 99 percent of password spray attacks use legacy authentication protocols. These attacks would stop with basic authentication disabled or blocked.

Note

Effective October 1, 2022, we will begin to permanently disable Basic Authentication for Exchange Online in all Microsoft 365 tenants regardless of usage, except for SMTP Authentication. For more information, see the article Deprecation of Basic authentication in Exchange Online

Alex Weinert, Director of Identity Security at Microsoft, in his March 12, 2020 blog post New tools to block legacy authentication in your organization emphasizes why organizations should block legacy authentication and what other tools Microsoft provides to accomplish this task:

This article explains how you can configure Conditional Access policies that block legacy authentication for all workloads within your tenant.

While rolling out legacy authentication blocking protection, we recommend a phased approach, rather than disabling it for all users all at once. Customers might begin disabling basic authentication on a per-protocol basis, by applying Exchange Online authentication policies, then (optionally) also blocking legacy authentication via Conditional Access policies when ready.

Customers without licenses that include Conditional Access can make use of security defaults to block legacy authentication.

Prerequisites

This article assumes that you're familiar with the basic concepts of Microsoft Entra Conditional Access.

Note

Conditional Access policies are enforced after first-factor authentication is completed. 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.

Scenario description

Microsoft Entra ID supports the most widely used authentication and authorization protocols including legacy authentication. Legacy authentication can't prompt users for second factor authentication or other authentication requirements needed to satisfy Conditional Access policies, directly. This authentication pattern includes basic authentication, a widely used industry-standard method for collecting user name and password information. Examples of applications that commonly or only use legacy authentication are:

  • Microsoft Office 2013 or older.
  • Apps using mail protocols like POP, IMAP, and SMTP AUTH.

For more information about modern authentication support in Office, see How modern authentication works for Office client apps.

Single factor authentication (for example, username and password) isn't enough these days. Passwords are bad as they're easy to guess and we (humans) are bad at choosing good passwords. Passwords are also vulnerable to various attacks, like phishing and password spray. One of the easiest things you can do to protect against password threats is to implement multifactor authentication (MFA). With MFA, even if an attacker gets in possession of a user's password, the password alone isn't sufficient to successfully authenticate and access the data.

How can you prevent apps using legacy authentication from accessing your tenant's resources? The recommendation is to just block them with a Conditional Access policy. If necessary, you allow only certain users and specific network locations to use apps that are based on legacy authentication.

Implementation

This section explains how to configure a Conditional Access policy to block legacy authentication.

Messaging protocols that support legacy authentication

The following messaging protocols support legacy authentication:

  • Authenticated SMTP - Used to send authenticated email messages.
  • Autodiscover - Used by Outlook and EAS clients to find and connect to mailboxes in Exchange Online.
  • Exchange ActiveSync (EAS) - Used to connect to mailboxes in Exchange Online.
  • Exchange Online PowerShell - Used to connect to Exchange Online with remote PowerShell. If you block Basic authentication for Exchange Online PowerShell, you need to use the Exchange Online PowerShell Module to connect. For instructions, see Connect to Exchange Online PowerShell using multifactor authentication.
  • Exchange Web Services (EWS) - A programming interface that's used by Outlook, Outlook for Mac, and non-Microsoft apps.
  • IMAP4 - Used by IMAP email clients.
  • MAPI over HTTP (MAPI/HTTP) - Primary mailbox access protocol used by Outlook 2010 SP2 and later.
  • Offline Address Book (OAB) - A copy of address list collections that are downloaded and used by Outlook.
  • Outlook Anywhere (RPC over HTTP) - Legacy mailbox access protocol supported by all current Outlook versions.
  • POP3 - Used by POP email clients.
  • Reporting Web Services - Used to retrieve report data in Exchange Online.
  • Universal Outlook - Used by the Mail and Calendar app for Windows 10.
  • Other clients - Other protocols identified as utilizing legacy authentication.

For more information about these authentication protocols and services, see Sign-in log activity details.

Identify legacy authentication use

Before you can block legacy authentication in your directory, you need to first understand if your users have client apps that use legacy authentication.

Sign-in log indicators

  1. Sign in to the Microsoft Entra admin center as at least a Reports Reader.
  2. Browse to Identity > Monitoring & health > Sign-in logs.
  3. Add the Client App column if it isn't shown by clicking on Columns > Client App.
  4. Select Add filters > Client App > choose all of the legacy authentication protocols and select Apply.
  5. Also perform these steps on the User sign-ins (non-interactive) tab.

Filtering shows you sign-in attempts made by legacy authentication protocols. Clicking on each individual sign-in attempt shows you more details. The Client App field under the Basic Info tab indicates which legacy authentication protocol was used.

These logs indicate where users are using clients that are still depending on legacy authentication. For users that don't appear in these logs and are confirmed to not be using legacy authentication, implement a Conditional Access policy for these users only.

Additionally, to help triage legacy authentication within your tenant use the Sign-ins using legacy authentication workbook.

Indicators from client

To determine if a client is using legacy or modern authentication based on the dialog box presented at sign-in, see the article Deprecation of Basic authentication in Exchange Online.

Important considerations

Clients that support both legacy and modern authentication might require a configuration update to move from legacy to modern authentication. If you see modern mobile, desktop client or browser for a client in the Sign-in logs, it's using modern authentication. If it has a specific client or protocol name, such as Exchange ActiveSync, it's using legacy authentication. The client types in Conditional Access, Sign-in logs, and the legacy authentication workbook distinguish between modern and legacy authentication clients for you.

  • Clients that support modern authentication but aren't configured to use modern authentication should be updated or reconfigured to use modern authentication.
  • All clients that don't support modern authentication should be replaced.

Important

Exchange Active Sync with Certificate-based authentication (CBA)

When implementing Exchange Active Sync (EAS) with CBA, configure clients to use modern authentication. Clients not using modern authentication for EAS with CBA are not blocked with Deprecation of Basic authentication in Exchange Online. However, these clients are blocked by Conditional Access policies configured to block legacy authentication.

As another option, CBA performed at a federation server can be used with modern authentication.

If you're using Microsoft Intune, you might be able to change the authentication type using the email profile you push or deploy to your devices. If you're using iOS devices (iPhones and iPads), you should take a look at Add e-mail settings for iOS and iPadOS devices in Microsoft Intune.

Block legacy authentication

There are two ways to use Conditional Access policies to block legacy authentication.

Directly blocking legacy authentication

The easiest way to block legacy authentication across your entire organization is by configuring a Conditional Access policy that applies specifically to legacy authentication clients and blocks access. When assigning users and applications to the policy, make sure to exclude users and service accounts that still need to sign in using legacy authentication. When choosing the cloud apps in which to apply this policy, select All cloud apps, targeted apps such as Office 365 (recommended) or at a minimum, Office 365 Exchange Online. Organizations can use the policy available in Conditional Access templates or the common policy Conditional Access: Block legacy authentication as a reference.

Indirectly blocking legacy authentication

If your organization isn't ready to block legacy authentication completely, you should ensure that sign-ins using legacy authentication aren't bypassing policies that require grant controls like multifactor authentication. During authentication, legacy authentication clients don't support sending MFA, device compliance, or join state information to Microsoft Entra ID. Therefore, apply policies with grant controls to all client applications so that legacy authentication based sign-ins that can’t satisfy the grant controls are blocked. With the general availability of the client apps condition in August 2020, newly created Conditional Access policies apply to all client apps by default.

What you should know

It can take up to 24 hours for the Conditional Access policy to go into effect.

Blocking access using Other clients also blocks Exchange Online PowerShell and Dynamics 365 using basic auth.

Configuring a policy for Other clients blocks the entire organization from certain clients like SPConnect. This block happens because older clients authenticate in unexpected ways. The issue doesn't apply to major Office applications like the older Office clients.

You can select all available grant controls for the Other clients condition; however, the end-user experience is always the same - blocked access.

Next steps