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. 


Mailbag1.pngHere 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.



mailbag2.pngHere 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


Relative to the approach described in your last paragraph, particularly "The protocol connection is denied before checking the credentials against Azure AD," is there any way to explain this ongoing mystery?  If the "attackers don’t even get to try to use passwords," why are lockouts still occurring?


Occasional Visitor

And for customers that don't have Azure AD premium? 

Senior Member

When federated with AD FS we find that the conditional access policy blocks the request after the WS-Trust authentication to AS FS so that lockouts are still a problem.  Mostly coming in as SMTP and IMAP requests through Exchange Online.  Even disabling these protocols on exchange online is evaluated after the authentication.  ADFS extranet lockout was the only thing that helped us out with that.  

Senior Member

We came up with a unique approach in our org. We don't use O365/AAD MFA, but rather Duo with a Conditional Access custom control. Due to this, we don't get app password capability, and legacy protocols are not inherently blocked.


What we do is that we've written our Conditional Access policies to only allow legacy protocols on our corporate network. Connections via legacy protocols from anywhere else get blocked. (And of course, our Duo custom control is enforced on users and Modern Auth aware clients)


IMAP/POP/ActiveSync are all disabled by default in Exchange Online. If someone needs IMAP access, we simply enable it on the mailbox, and let the user know that they must be on-site or on our VPN. (Which is also Duo-protected)


This lets us prevent unauthorized access via legacy protocols, but still let users cling to Thunderbird if they just really, really don't want to join the rest of us in the 21st century.


@Brian .  If you have blocked basic auth in EXO and allowed for some time for the policy to apply and still see unsuccessful sign ins for that user/protocol, send me an email at andres.canello@ms and I'll check for you. 


@Cyphel  We've heard that feedback and we are working on a solution.


@Loren Bain Conditional Access policies are evaluated/applied only after authentication (i.e.: after the attacker gets an opportunity to try passwords at your AD FS), same for disabling protocols at the mailbox level (set-casmailbox) and CAR (client access rules). This is why we recommend disabling basic auth with Authentication Policies, that way Exchange just ignores the auth request. I have put together the following slides to walk customers through an attack and what controls are applied and especially when in the auth flow. Check them out (we are looking into publishing these in our documentation) https://www.slideshare.net/AndresCanello/azure-ad-password-attacks-logging-and-protections


@ajc196  great, for the best protection, consider disabling Exchange protocols using Authentication Policies instead of set-casmailbox. Auth Policies let you do it per-mailbox, per-protocol and for the entire org as well. See my other comment about processing order in the auth flow.


@AndresCanello Thanks for the offer. Yes, we disabled basic authentication across EXO for all users last November. It's the one and only authentication policy.


I do, see, however, in the latest AAD logs, that there hasn't been an IMAP "Account is locked because user tried to sign in too many times with an incorrect user ID or password" since March 3rd, so it's possible that it finally stopped.  It has died down before, but never for this long. So, unless you still want to take a look at things, maybe it's just best to sit tight for now and see if it truly has stopped.

Senior Member

Does this statement still apply today?



When a client app can use a legacy authentication protocol to access a cloud app, Azure AD cannot enforce a conditional access policy on this access attempt. To prevent a client app from bypassing the enforcement of policies, you should check whether it is possible to only enable modern authentication on the affected cloud apps.


Therefore in order for any type of conditional access policy to be evaluated the client must support modern authentication.... ?

New Contributor

@AndresCanello "We've heard that feedback and we are working on a solution."

Any updates on this?

Customers that don't have Azure AD premium still need to take care of this.



@Sean Stark Good pick up. That article contains old info and we are taking it down.


@anon_ We are working on it, stay tuned!


Just in case it's overlooked, since it's only mentioned at the end of the article, this method doesn't require Premium:



@Brian .  We added the ability to block legacy authentication in conditional access and so we recommend you start here first.. You will require Azure AD P1 license to leverage conditional access witch will give you flexibility to support users or apps that still need to use protocols with legacy authentication and can block the rest. @AndresCanello  has suggested some other scenarios in the post that you may want to look based on your environment setup where you may not require Azure ADP

Occasional Visitor

Is it not possible to have a report that tells me all the legacy auth for a period of time? I've tried looking at the logs for 200,000 sign-ins a day and it's difficult to get the detail required. For example, Other clients; Older Office clients lists Microsoft Office 15.0, I assume that's not Legacy Auth? How about:

Android-Mail 2019.04.14
CalendarAgent 316.1
CalendarAgent 361.2
CalendarAgent 399.2
CalendarAgent 416.4
CalendarAgent 416.5
ExchangeWebServices 287.1
ExchangeWebServices 287.4
ExchangeWebServices 5.0
ExchangeWebServices 6.0
ExchangeWebServices 7.2
Microsoft Office 14.0
Microsoft Office 15.0
Microsoft Office 16.0
Python Requests 2.18
Senior Member



I have extracted the "Other Clients" sign-in events for the past 30 days and have a few questions:


- "Other Clients; MAPI": We see a large amount of Office 2016 clients doing Legacy Auth which is odd as ADAL is supposed to be enabled by default? How can Outlook 2016 clients still do Legacy Auth?


- "Other Clients" & "Other Clients; Older Office Clients": There is no significant details to classify what has been attempted exactly? No Browser or OS info or ResourceDisplayName… we only have some different AppID which are unknown to us!


- Is there any documentation on these AppID, I checked on our tenant and they are unknown?

  • dcdaf69a-8ab6-4fea-9731-6c5a5d54d151
  • d176f6e7-38e5-40c9-8a78-3998aab820e7
  • a039b054-9847-48fb-824b-1c5b848953e0
  • 597cf567-d52d-4c00-aca6-b2126beb3fa1
  • 4e31c259-4969-4c6a-9e94-64c5c9536c29
  • bfc44fc5-2fe3-4d02-98ec-1e5967475f68
  • dcdaf69a-8ab6-4fea-9731-6c5a5d54d151


Many thanks for your help to get us to a legacy auth free world :-)



Tonino Bruno