Azure AD Mailbag: Discovering and blocking legacy authentication

Hey there,

 

I am Andres Canello from the Azure AD Get-to-Production team. I'm a long time Exchange guy now working on Identity. I am very passionate about helping customers prevent password-based attacks and it is a major topic of concern from customers. Legacy authentication is a key part of these conversations because these protocols and clients are commonly used to perform brute-force or password spray attacks. In this post, I will talk about the challenges with legacy authentication and how you can use Azure AD and Microsoft Exchange Online to get better access control.

 

Q1: What is "legacy authentication" and what's wrong with it?

Generally speaking, legacy authentication refers to protocols that use basic authentication (Basic Auth); they only require a single factor authentication of username and password and typically cannot enforce a second factor as part of the authentication flow. On the other hand, modern authentication (Modern Auth) can require second factor authentication, usually the app or service will pop up a browser frame so the user can perform whatever is required as a second factor. This can be entering a one-time code, approving a push notification on the phone, or answering a phone call.

 

Another key difference is that in a legacy authentication pattern, the client app or service collects credentials and then validates them against an authority. Essentially, the app or service is trusted to handle credentials in a secure way. In modern authentication, however, credentials are only provided to a trusted authority (i.e. a redirect to Azure AD or AD Federation Services) and after authentication a token is issued for the application or service to act on a user’s behalf.

 

Examples of protocols that use legacy authentication are POP3, IMAP4, and SMTP. There are other protocols that use Basic Auth and Modern Auth such as MAPI and EWS.

 

So, what's the problem?

 

Single factor authentication is not enough these days to remain secure! Passwords are weak as they are easy to guess and we (humans) are bad at choosing strong passwords; we tend to just give them to attackers (i.e phishing). One of the easiest things that can be done to protect against password threats is implementing multi-factor authentication (MFA). So even if an attacker gets in possession of a user's password, the password alone is not enough to successfully authenticate and access data and resources.

 

Protocols that use legacy authentication, especially the ones that are used to retrieve emails like POP3, IMAP and EWS are very popular ways to perform password brute-force and password spray attacks because if one of the username and password combinations is right, the attacker will typically get access to the user's emails.

 

Q2: Ok, what do I do with these protocols then?

The recommendation is to block legacy authentication, or if you have exceptions where you need to allow their use, apply some controls that only allow them for specific users and locations. Before you do that, and because I don't want you to get a thousand calls to your Help Desk, you should start by understanding their usage in your organization.

 

Last year, we made a few improvements to the sign-in logs in Azure AD, so now you get events a lot quicker and you get more info for each event. Part of this info is the Client App property, where we tell you the protocol/app that was used to perform the sign-in. 

 

Here is a snapshot from the Azure AD Portal, Sign-in logs with the added as a column and filter option.

The first thing you need to do is to spend some time analyzing the logs to understand the usage of these clients and protocols across your organization. To do this, you might want to download the logs to be able to slice and dice them with Microsoft Excel, or even better, you might want to pull them into your security information and event management (SIEM) system, which might give you some more powerful data analysis capabilities and alerting. To understand how you can get the logs into your SIEM, you should have a look at this post. Once you understand who is using what, you might need to upgrade clients to versions that support Modern Auth or convince people to stop using protocols like IMAP4 and welcome them to this century.

 

Q3: Alright, I'm ready to enforce some control here, how do I do it?

Until last year, there were two ways of blocking legacy authentication in Azure AD:

• In federated environments (i.e. using AD FS), you could use claim rules to allow certain protocols and deny access to the rest. This gets messy when you need to start adding conditions and exceptions.
• Enforcing MFA per user will force users to use app passwords for legacy authentication protocols, however, if you disallow its use, you effectively block these protocols. The bad news here is that you can't apply any conditions, it's all or nothing. Also, enforcing MFA per user is not really the way we recommend doing it these days – conditional access gives you more flexibility.

Last year, we added the ability to block legacy authentication in conditional access and so we recommend you start here first. With conditional access you gain flexibility to support users or apps that still need to use protocols with legacy authentication and can block the rest.

 

For example, if you have an app supporting a business process that uses IMAP to retrieve email from an MS Exchange Online mailbox, you can use conditional access to allow that flow only for that user if the source IP is one of your IPs, and block every other attempt. Read how to use conditional access to block legacy authentication to learn more.

 

 

Here is the new Client App condition that allows you to target Other Clients

Something that has created some confusion is that conditional access policies don't include legacy authentication clients by default, this means that if you have a conditional access policy enforcing MFA for all users and all cloud apps, it doesn't block legacy authentication clients (or "Other clients", as the CA UI refers to them). Legacy authentication clients can still authenticate with only username and password. To block legacy authentication, just create a new policy.

 

Another way to block legacy authentication is blocking it service-side or resource-side (versus at the authentication platform). We also recommend this approach if combined with an Azure AD Conditional Access policy. For example, in MS Exchange Online, you could disable POP3 or IMAP for the user. The problem with this is that you don't want to block protocols that can do legacy and modern authentication (i.e EWS, MAPI) as you most likely still need them. To help with this, MS Exchange Online released a new feature called authentication policies which you can use to block legacy authentication per protocol for specific users or for the entire organization. I like this because with this approach, you are blocking the attempt to use the protocol at the very beginning meaning that attackers don’t even get to try to use passwords. The protocol connection is denied before checking the credentials against Azure AD or AD Federation Services, so the enforcement is done pre-authentication. Conditional access policies are evaluated after the user (or attacker) has authenticated, so the enforcement is done post-authentication. Read the Exchange Online Authentication Policies documentation for more info.

 

For any questions you can reach us at AskAzureADBlog@microsoft.com, Tech Communities or on Twitter @AzureAD, @MarkMorow and @Alex_A_Simons. You can also ask questions in the comments of this post.

 

-Andres Canello