This blog post is honestly a few years too late, but since Microsoft cancelled their initial deadline for preventing the use of legacy authentication and provided new ways to connect to older protocols, this is still relevant.
In short, legacy authentication refers to the ability to send a basic username and password to an endpoint for authentication.
The problem with legacy authentication is that it typically cannot leverage all of the new security capabilities we have available, like Multi-factor Authentication. A common issue has been that organizations are configuring Multi-Factor Authentication policies and requirements, which are honored for connections that are capable of handling the MFA challenge, but are completely ignored in legacy authentication contexts! This can be a major blind spot.
Furthermore, due to the ease of automation and existing toolsets, there is a much lower barrier to entry when performing password stuffing or password spraying attacks against an environment that has legacy authentication available.
There are several things we can do within both Azure AD and Exchange Online to protect accounts against legacy authentication attacks or control bypasses. In this post, I’d like to go through some of the different methods available as well as walk through the implications of each in terms of what the user experience and log generation would be like.
Before getting started, it is important to distinguish between legacy protocols and legacy authentication (also referred to as “basic authentication”). Both of these phrases got thrown around a lot, and references to legacy protocols still exist in the Microsoft authentication. Contextually, it can make things difficult to understand, for example, when we can use Modern Authentication to connect to a “legacy protocol” such as IMAP. In this post, when I say protocol, I literally mean the ability to use a specific application or protocol within the Microsoft environment. When I say authentication, I mean whatever process is utilized to transmit a username, password, and other challenge information to the authentication provider. There exists a serious need to distinguish this now, because previous guidance to disable “protocols” can lead to unintended issues.
Option 1: Disabling the protocol (Exchange Online)
From Recipients > Mailboxes within the Exchange Admin Center, you can select a mailbox and then “manage email apps settings” to pick and choose which protocols are available for use on any given mailbox.
Alternatively, with Exchange Online Powershell, you can use the Set-CasMailbox command to set specific protocols like IMAP and POP3 to False.
Example: set-casmailbox [email protected] -ImapEnabled $false
Once this is configured, users still have the ability to use a legacy authentication method to access IMAP or other protocols. However, the client will not be able to connect, regardless if the user provides a legitimate username and password combination due to the protocol not being enabled. Different clients will return different errors, like a generic “incorrect username or password” or something like Bluemail, seen here, specifying there was an error and it could not connect to the server.
From Azure Active Directory, you can see that the authentication was successful, despite the client not being able to access the mailbox. That is because no control was put on authentication, just protocol use.
As noted before, because I did not have any controls related to blocking legacy authentication, if the protocol had been available on my account, the MFA condition would not have been evaluated. This can be a real controls gap in some environments that results in a “bypass” of MFA controls.
Administrators should take care when disabling protocols from accounts, now that it is possible to use IMAP with OAuth2, for example. The same goes for disabling ActiveSync; clients like the Mail app on iOS that use modern authentication will break if you disable the protocol itself. If your accounts don’t need access to IMAP, and have no conceivable need for IMAP (for example, if you don’t allow for third party applications and intend to push users towards specific apps like Outlook anyway)–sure, turn it off. Just be careful when you disable some of these, in general.
When investigating malicious logins, it may be useful to check if successful IMAP logins are actually prevented by a lack of IMAP access on the account if this is something that is being leveraged in the environment.
Another thing to note is if you are only using this to block “legacy” access, you may still have legacy authentication available via other endpoints or protocols. This is not a holistic method to block all legacy authentication attempts.
Option 2: Authentication Policies (Exchange Online)
Authentication Policies extend the ability to target specific protocols on accounts by targeting only authentication and keeping the protocol available when used with Modern Authentication. You can also set a default Authentication Policy that can apply to all accounts without having to configure the Authentication Policies on each individual user.
When creating an authentication policy in Exchange Online with the “New-AuthenticationPolicy” command, all available legacy authentication methods are automatically blocked by that policy. You must then opt in by setting each individual AllowBasicAuth* parameters per protocol for that policy, if any exceptions are required. (Don’t be mislead by the parameters available to New-AuthenticationPolicy when looking at the online reference–parameters related to blocking basic auth are for Exchange on-prem).
You can also configure this for the entire tenant through the Microsoft 365 Admin Center‘s Modern Authentication settings. Apparently, this uses Authentication Policies on the back end and allows you to disable legacy authentication access for all users. This is an all or nothing config, so make sure you don’t have anything still relying on the configured legacy authentication protocols if you do this. If you still need access to legacy authentication in limited contexts, I recommend Conditional Access instead.
Note: don’t take this screenshot as a full example; if you’re truly looking to block against legacy authentication attacks the settings here aren’t sufficient if you’re not also using other controls.
When using authentication policies, the Exchange Online service no longer accepts basic authentication for the affected accounts. Therefore, it pretty much does nothing, including forwarding the credentials to Azure AD. No logs will appear in Azure AD to indicate whether there was a failed or a successful attempt to sign in when this is configured.
Similar to when the protocol is disabled, when legacy authentication is not available, the sign in will always fail; only in this case, administrators can’t see attempts in the logs. Here is another example, this time from Thunderbird.
Option 3: Conditional Access (Azure AD)
Conditional Access can be used to constrain a login session based on certain conditions. One benefit of conditional access is that you can create exclusions within polices per user, app, or location. This is useful, for example, if you still have some accounts that can’t be migrated to something that supports Modern Authentication yet but understand where the account should typically be used from. There are a lot of things conditional access can do, but specifically I will focus on utilizing conditional access to block legacy authentication.
The downside of conditional access is that, unlike the previous settings in Exchange Online, Conditional Access policies within Azure AD require that users have at least an Azure AD P1 license. (Don’t be fooled; a single P1 license in your environment gives you the capability to scope Conditional Policies to any number of users–just keep in mind your licensing and try to ensure you’re scoping your policies correctly and in a compliant manner).
The recommendation for blocking legacy authentication is to create a policy with a client apps condition of Exchange ActiveSync clients and Other clients with the access control grant set to block access. It will look something like this:
This will block a valid username and password authentication attempt against Azure AD from a client utilizing basic authentication. Most clients will treat this as a bad password attempt when it receives the failure from Azure AD. (Note: provided there are no other controls in place, existing ActiveSync profiles that are leveraging legacy authentication will no longer be able to interact with the mailbox. The account will have a single message in the session that indicates that the user’s access to email has been blocked and to contact their IT department. It’s a little misleading–move the user to a client that can perform modern authentication. In some cases, like for environments that had to enable Modern Authentication, older profiles on modern auth capable clients, like the default Mail app on modern versions of iOS, will need to be deleted and recreated to sign in via modern auth).
The Azure AD logs can be used to see where the conditional access policy created a “failure” condition. To find these, filter for status = failure, conditional access = failure, and filter by the relevant legacy authentication client apps available. If you don’t filter by the client app, you may see a lot of other conditional access failures for MFA or other policies.
In cases where conditional access was “Not Applied,” the user (or attacker) did not provide valid credentials.
Again, MFA is not evaluated for the successful username and password, but the legacy authentication is blocked. Azure AD will not provide a token for access to resources.
Option 4: Security defaults (Azure AD)
If you do not have P1 licensing, you can still leverage Security Defaults for Azure Active Directory.
“Manage Security Defaults” is a single switch under the properties of your Azure Active Directory Tenant.
Security defaults will act like conditional access in blocking legacy authentication attempts. It also will enforce MFA in some contexts, but users can only enroll via the Microsoft Authenticator app.
Security defaults are not compatible with Conditional Access (in fact, if you’re using any conditional access policies, you’re not able to turn this on). Security defaults also do not have the ability to define any kind of exceptions. It is a great tool if it is all you have access to, but it can lead to issues if there are any accounts or situations that would not be compatible with the all-or-nothing settings.
What Option is Best?
In general, if I had to rank the methods I would choose:
- Conditional Access (most powerful; covers all contexts that leverage Azure AD; most configurable when exceptions are required; easiest to set up)
- Authentication Policies (still allows access to the underlying protocols in modern auth contexts; can be scoped to users or set for the organization)
- Security Defaults (works in a pinch without extra cost; won’t miss protecting a specific protocol or authentication type)
- Disabling the protocol (can leave unintended gaps where legacy authentication is available; can cause issues if the protocol is paired with Modern Authentication in the future)
Every environment is different, though.
Bonus details: Modern Authentication with IMAP
After Microsoft announced that they would be discontinuing the use of legacy authentication in 2020, they offered the ability to use IMAP with OAuth2. If your solution was to block IMAP basic authentication through Authentication Policies or use conditional access to block legacy authentication, there are no issues with clients that have updated to use OAuth2, such as Thunderbird. However, if the protocol itself was disabled via Powershell or in the Exchange Admin Center, the user will be able to successfully authenticate but the client will not work.
For example, here is going through the configuration with Thunderbird while IMAP is disabled on my account. Here are the server settings, specifying the use of OAuth2 instead of basic authentication.
This successfully opens an authentication windows which uses Modern Authentication. We can answer an MFA challenge successfully in this context.
Since this is OAuth2, I have to approve the permissions requested for the application to access my account.
Thunderbird can’t access the mailbox. Nothing will load, and I get an error pop up.
However, if you check the logs in Azure AD, everything looks fine! Note the client app no longer is IMAP.
Once IMAP is reenabled via Set-CasMailbox or the Exchange Admin Center, Thunderbird is able to successfully retrieve mail via IMAP after authenticating with an approved, modern method.
Outcome Comparisons
| Protocol Status | Authentication Status | Azure AD Status | Conditional Access Status | Result | Note |
| Enabled | Legacy auth used, allowed | Success | Not Evaluated | User can access mailbox, potential MFA bypass | N/A |
| Disabled | Legacy auth used, allowed | Success | Not Evaluated | No mailbox access | Option 1 |
| Disabled | Legacy auth used, Disabled by Authentication Policy | Not logged | Not logged | No mailbox access | Options 1 and 2 |
| Enabled | Legacy auth used, Disabled by Authentication Policy | Not logged | Not logged | No mailbox access | Option 2 |
| Disabled | Legacy auth used, Blocked by Conditional Access | Failure | Failure | No mailbox access | Options 1 and 3/4 |
| Enabled | Legacy auth used, Blocked by Conditional Access | Failure | Failure | No mailbox access | Option 3/4 |
| Disabled | Modern auth used, all relevant conditional access policies met | Success | Success | No mailbox access | Option 1 |
| Enabled | Modern auth used, all relevant conditional access policies met | Success | Success | User can access mailbox | N/A |
Links and Resources
Using Set-CasMailbox to change the availability of protocols: https://docs.microsoft.com/en-us/powershell/module/exchange/set-casmailbox?view=exchange-ps
Disable legacy authentication in Exchange Online with Authentication Policies or via the Microsoft 365 Admin Center: https://docs.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/disable-basic-authentication-in-exchange-online
Prevent Legacy Authentication using Conditional Access Policies in Azure AD: https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/block-legacy-authentication
Using Security Defaults in Azure Active Directory: https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/concept-fundamentals-security-defaults
Most Recent Update (Feb 2021) Regarding Future Availability of Legacy Authentication: https://techcommunity.microsoft.com/t5/exchange-team-blog/basic-authentication-and-exchange-online-february-2021-update/ba-p/2111904