Still using Legacy Authentication???

You know it’s bad, and you have a policy to block it but are you still at risk?

I recently had a fun discussion with the folks at SCI Fridays where we likened legacy authentication to letting your children go naked in public. https://www.linkedin.com/video/event/urn:li:ugcPost:6867114168898596864/

Legacy Authentication, or basic authentication as it is also known, refers to authenticating with only a username and a password. Certain protocols in Exchange Online especially only support legacy forms of authentication. Because these protocols DO NOT support modern authentication, they cannot support multi-factor authentication (MFA).

Nearly 100% of password spray attacks, credential stuffing, and brute force attacks use legacy authentication protocols! Because legacy authentication protocols don’t support interactive sign-in, which is required for additional security challenges like multi-factor authentication and device authentication. So, attackers love the legacy protocols.

These legacy protocols in Exchange Online perform pre-authentication before passing the request on to Azure Active Directory and then only Conditional Access policies are applied. The basic steps are shown in the image below.

1. The email client sends the username and password to Exchange Online.
2. Exchange Online sends the username and password to Azure Active Directory.
3. Azure Active Directory returns a user ticket to Exchange Online, and the user is authenticated.

Conditional Access policies are only evaluated after step 2 and before step 3 in the above process. Therefore, to properly eliminate the risk of attacks via Exchange Online Legacy protocols the protocols must either be switched off altogether or one needs to create Exchange Authentication policies using PowerShell. You can check out my previous block for details on how to do that.

Microsoft recommend a Conditional Access policy to block legacy authentication, and there are 2 ways of doing that with Conditional Access policies:

1. Directly blocking legacy authentication clients – A conditional access policy that applies a block access control if the client app meets the conditions of being either “Exchange ActiveSync Clients” or “Other clients”. All conditions of your policy must be met, and then only will the access be blocked.
2. Indirectly blocking legacy authentication – any policy that grants access but has not been configured for specific client apps, or, if created before August 2020, has all client apps selected (Microsoft changed the behavior of the client apps condition in August 2020).

However, I am of the opinion that a conditional access policy on it’s own is not enough. I’ve come across 3 scenarios where customers are at risk:

1. Customers don’t have an Azure AD Premium license required to create CA policies and haven’t enabled Security Defaults (Security defaults is pre-configured settings to protect tenants that don’t have conditional access policies – you can read more about it on my blog)
2. They have a misconfigured Conditional Access policy (incorrect client apps selected, incorrect cloud apps selected, or both etc.)
3. Or they just don’t have a Conditional Access policy.

Most organizations believe that having a Conditional Access policy enabled to block legacy authentication is sufficient. The reality is that even with a Conditional Access policy, because of the way the legacy protocols interact with Exchange Online before AAD and Conditional Access policies are even evaluated, tenants are still at risk of GAL Dumps and certain attacking tools like MailSniper. Evidence of this can be seen in the sign-ins logs in Azure Active Directory for failed sign-in attempts from countries other than where your users are generally located.

Microsoft will fix the problem (as much as they can without breaking your stuff)

Effective October 1, 2022, Microsoft will begin disabling Legacy authentication for Outlook, EWS, RPS, POP, IMAP, and EAS protocols in Exchange Online.[1]
In the meantime however, Microsoft have given Admins the ability to disable any/all of the above protocols from the Microsoft Admin Center (https://admin.microsoft.com/#/Settings/Services/:/Settings/L1/ModernAuthentication) by simply unchecking the allowed protocols that you know are not in use and can be switched off.

The above method is essentially creating a default Exchange authentication policy for everyone that disables the protocol. If you want granularity however, you are better off creating custom Exchange Authentication policies yourself. As I outline in my previous post – Block Legacy Authentication in Office 365 – MattChatt
But before enabling, please, please consult the sign-in logs to establish if you have a legitimate requirement for Legacy Authentication. Alex Weinert, from Microsoft wrote this post about collecting the information from the sign-in logs

---

[1] Deprecation of Basic authentication in Exchange Online | Microsoft Docs