Microsoft Secure Tech Accelerator
Apr 03 2024, 07:00 AM - 11:00 AM (PDT)
Microsoft Tech Community
Azure AD Mailbag: Discovering and blocking legacy authentication
Published Mar 15 2019 09:00 AM 69.4K Views
Microsoft

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.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 ClientsHere 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

42 Comments
Bronze Contributor

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?

https://github.com/MicrosoftDocs/OfficeDocs-Exchange/issues/339

Copper Contributor

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

Copper Contributor

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.  

Steel Contributor

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.

Microsoft

@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. 

Microsoft

@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

Microsoft

@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.

Bronze Contributor

@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.

Copper Contributor

Does this statement still apply today?

 

https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/conditional-access-for-ex...

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.... ?

Copper 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.

Thanks.

Microsoft

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

 

@anon_ We are working on it, stay tuned!

Bronze Contributor

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

https://docs.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/disable-basic-authen...

Microsoft

@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

Copper Contributor

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
clview.exe
ExchangeWebServices 287.1
ExchangeWebServices 287.4
ExchangeWebServices 5.0
ExchangeWebServices 6.0
ExchangeWebServices 7.2
groove.exe
lync.exe
MacOutlook 0.0.0.150830
MacOutlook 14.5.9.151119
MacOutlook 14.6.0.151221
MacOutlook 14.7.2.170228
MacOutlook 14.7.3.170325
MacOutlook 14.7.7.170905
MacOutlook 15.30.0.170107
MacOutlook 15.31.0.170216
MacOutlook 15.33.0.170409
MacOutlook 16.10.0.180210
MacOutlook 16.16.9.190412
MacOutlook 16.20.0.181208
MacOutlook 16.24.0.190414
MacOutlook 16.25.0.190512
MacOutlook 16.8.0.171210
Microsoft Office 14.0
Microsoft Office 15.0
Microsoft Office 16.0
Python Requests 2.18
searchprotocolhost.exe
Brass Contributor

Hi,

 

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 :)

 

Sincerely,

Tonino Bruno

Copper Contributor

@AndresCanello 

 

We're in the same boat as @Tonino Bruno . We have MAC Outlook 2016 users who are getting blocked when we apply the "block legacy CA policy" to them. 

 

Also, when looking at the logs for all older office clients, it doesn't provide us any details on the app. 

 

What exactly is this App ID - bfc44fc5-2fe3-4d02-98ec-1e5967475f68?

Copper Contributor

We're also experiencing a similar issue with what appear to be Office 2016 users.

 

I intend to implement a Conditional Access rule to Block Legacy Auth but I'll have to make exception for the handful of old Office 2010 clients that are authenticating to 365 until we can engineer them out.

 

However, I have quite a few (about 5%) of users who are displaying a Legacy Authentication where the Application Name shows in the Sign-In Logs as "Microsoft Office 2016" or blank with "bfc44fc5-2fe3-4d02-98ec-1e5967475f68" as the App ID!

 

Any clues as to why this is would be welcome. Currently I'm intending to implement the policy with all these in an exceptions group but strategically miss one or two out and see what the issue is when they report a problem...basically cutting the wire to see what goes off!!

 

If I find anything I'll let you know.

Regards,

Andy

Copper Contributor

I'm having similar behavior to the people above me. We have been using Modern Auth with a Conditional Access Policy that integrates Duo 2FA. When enabling the preview policy to disable legacy auth, about 5% of users are unable to authenticate through any Office365 bundled applications (Teams works fine, Web works fine). I did troubleshooting with one user and even with a freshly installed Office 365 Pro Plus (used the cleanup tool to uninstall and then restart and reinstall) it still fails to authenticate.

 

Basic InfoBasic InfoDevice InfoDevice InfoConditional AccessConditional Access

Copper Contributor

@Kane316The issue with the failing Office 2016 on the Mac is likely due to the authentication profile which was not automatically converted from legacy to modern. To solve this you only need to re-add the account via

  1. Click Outlook in the top ribbon and select Preferences
  2. Choose Accounts
  3. In the bottom left click the + (plus) button
  4. Select New Account
  5. Enter your email address and click continue
  6. You might be prompted for a password, once it had added the account click done
  7. To delete the old account select it from the accounts menu and click the - (minus) and click delete.

  

Brass Contributor

Also seeing other/older office clients authenticating with Application ID bfc44fc5-2fe3-4d02-98ec-1e5967475f68. What is this?

Copper Contributor

I'm seeing this also.  (Application ID bfc44fc5-2fe3-4d02-98ec-1e5967475f68).

Do we need to open a case with MS or can we get an answer here?

Microsoft

Hi all, thanks for your patience on this.

bfc44fc5-2fe3-4d02-98ec-1e5967475f68 is indeed Exchange Online. We made a change recently so these sign ins show up as the Exchange Online 00000002-0000-0ff1-ce00-000000000000. I recommend looking at Exchange Online's logs to understand more about the protocols being used.

@Tonino Bruno @Kane316 @AndyPointon @Thomas Foster @Marc Laflamme @Kevin Fletcher 

Brass Contributor

@AndresCanelloThank you for the explanation however I'm still not fully understanding on how to resolve these connections. We only have one user (incidentally myself) that is showing successful connection to Office 365 Exchange Online using Other Clients / Older Office Clients. I don't have anything else getting mail on my system other than Outlook. The connection happens every day at 2:23am.

 

I don't know what you mean by checking Exchange Online's logs as there are various logs collected from EXO that are split throughout the M365 Admin portal. According to the Email App Usage report, my account only uses Outlook Client, Mobile, and Web. What other logs would help? (The Exchange Admin Portal doesn't appear to have any logs)

 

Each of these successful sign-ins on the Azure Sign-Ins report has a Correlation ID. Can I use that somehow to track what exactly is happening?

Copper Contributor

@AndresCanello thanks for the article. Is it fair to say then that anything preceded with "Other" in the Client App portion of the sign in logs is considered basic authentication? Any other categories I should filter for when hunting this down? Thank you.

Microsoft

@Mammoth77 That is correct, log entries with "Other" are legacy authentication. ActiveSync is legacy auth as well, however it's treated as an special case because we can apply some other controls to it.

Copper Contributor

@AndresCanello Thank you very much for the response. This is very helpful!

Copper Contributor

@Marc Laflamme 

 

Did you ever have your concerns answered.  I would agree with what you are describing.

 

@AndresCanello

 
Iron Contributor

@Kevin Fletcher 

I've since reinstalled Windows on the offending workstation however I have not had a chance to re-evaluate the legacy connection report. I'll check it out and reply any findings.

Copper Contributor

I know this article is pretty old but I thought I might drop a note here.

I've tried doing this very same thing in my own tenant to try and stop spray attacks that are almost always sourced by IMAP4. I have a policy constructed similarly above but configured to allow legacy only from our public IP address but block any other attempts at legacy/basic auth. I have a pilot group and when I use the "What If" function in conditional access for those users outside of our IP it comes back and shows that it will block connection. However, when I look our sign in logs spray attacks are still happening against those users even with the policy active and the "What If" tool confirming the connection should be blocked.

This is absolutely maddening and the MS Support folks say "See, it is working because the attempt was blocked" but it wasn't blocked. My condition policy was not applied and the only reason it failed is because they hit the threshold for failed login attempts.

@AndresCanello 

Microsoft

Hi @Ryan Lounsbury ,

Remember that Conditional Access policies are only evaluated and applied after authentication, this is no different for legacy authentication. CA will only protect cases where an attacker has valid credentials and is able to authenticate, it does not prevent the attacker trying credentials (i.e.: spraying).

To completely remove the ability for attackers to use protocols that use legacy authentication, you should disable such protocols/auth method directly in Exchange Online. Here is an article that explains how to use Authentication Policies in Exchange Online to do do.

https://docs.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/disable-basic-authen...

 

Andres

Copper Contributor

@AndresCanello thank you for following up on my question. 

So, really, what we end up with is layered security where we are blocking authentication at the Exchange level for legacy authentication. Then, the conditional access policy at the Azure AD level provides a second layer of security should someone some-how get past the the first block (or more accurately if you need to allow IMAP/POP/etc... access for an account the Azure AD conditional access restricts it from being accessed except from a defined location/IP -- but in this case it wouldn't prevent a password spray attack). 

I've updated my test users to disable the legacy auth within Exchange Online. I'll watch the results of that change and if that works as expected I can start rolling that out more broadly. I was getting really frustrated there focusing on the Azure AD conditional access policy. 

Copper Contributor

@AndresCanello So, thanks to your advice I was able to get the blocking working... However I managed to blow out a number of desktop Outlook clients which had already been configured using modern authentication which is a special case of frustrating. 

I suppose the only thing that seems odd to me is that it appears managing a mailbox via the admin portal for portal.office.com and disabling POP/IMAP <> the Authentication Policy on the Exchange Online PowerShell implementation. It could be me misunderstanding something here but i'd think if I toggle off IMAP/POP from the Office 365 admin portal for the user under the Mailbox setting it should handle this w/o having to go in and define a policy via PowerShell for Exchange Online. 

Microsoft

Hi @Ryan Lounsbury , Exchange checks if a protocol is enabled for a mailbox after successful authentication. Additionally, protocols like EWS cannot be disabled because Outlook uses it. The best way it's by using Authentication Policies, so you only disable basic auth for the protocol.

As you mentioned, it's very much a layered approach, especially for handling exceptions.

 

Andres

Copper Contributor

@AndresCanello Makes total sense in that the admin settings via the portals are post-authentication and the Exchange authentication policies are pre-auth preventing connections by the disabled protocol. I was getting hung up on that but now it makes much more sense with your feedback and my experience working with it. 

Thanks again! I have my ducks sorted now.

Copper Contributor

Hey folks - hybrid AAD (passthrough auth) + on prem AD customer, trying to get to Hybrid Modern Auth to enable interop between Teams and SfB On-Prem, plus Skype Mobile to SfB On-Prem, amongst other things. We tried for 6 weeks to enable Hybrid Modern Auth, and simply could not get Outlook stable for hybrid users (primary mailbox in EXO, shared mailbox on-prem, etc.). What made this really tough to diagnose was the number of reg keys that influence the authentication modes, and the fact that there is n ogood way to do a packet trace (e.g. Fiddler is needed to decrypt the traffic, but this breaks other parts of the Outlook to Exchange data exchange). Curious if others have seen such issues, and whether the Identity team and the Outlook team can add significantly more diags into the Outlook debug mode to help out with these issues. 

Microsoft

Heads up that we made some changes on how legacy auth clients show up on the Azure AD Sign In logs. Anything other than 'Browser' and ‘Mobile apps and Desktop clients’ should be interpreted as legacy/basic auth. More changes and blog post coming soon.

Brass Contributor

Hi

 

We recently turned on the Block legacy authentication (Preview) in Conditional Access in preperation for Octobers deadline.However in doing so, we have a lot of MAC and iOS devices that are showing up as Other clients that are using upto date Outlook for MAC or iOS clients. Most of our Windows Outlook clients seem to be fine.

 

Initial investigation is that iOS and Mac devices are not dropping their legacy authentication profile and switching over to Modern authentication despite allowing long periods of time to do so. 

 

I opened a case with support but was directed here. We cant be the only ones experiencing this issue. Is there something we are missing? Or recommendations other than thousands of users calling us to remove and re-add their Outlook profile. @AndresCanello 

Microsoft

Hi @Dopplerdave ,

My knowledge on Mac is limited, but as far as I'm aware iOS mail client needs the user to re-add the account for it to be configured to use oAuth.

 

Brass Contributor

as mentioned by @Cyphel and @anon_ "what about those of us who do not have a premium license?" .....

You did mention way back "We've heard that feedback and we are working on a solution."

Any updates on this?

 

We may still be stuck needing to allow a single application to authenticate with a legacy protocol, with no way to allow that without a conditional access policy (the powershell authentication policy would not help us either).

 

I don't think they could turn off legacy authentication without allowing us non-premium license folks to be able to set up exceptions like this.  

 

They would not do that to us, right?    ;)

 

Thanks,

Betty

Copper Contributor

The Azure AD Sign-In logs do not identity Legacy Auth very well. The field for Client App will show for example "Exchange Activesync"  which does not tell you if it was Legacy or not.  Is there another more reliable way to identify Legacy sign-ins?

Brass Contributor

@Bill B. According to this article:

 

Basic Auth and Exchange Online – February 2020 Update
https://techcommunity.microsoft.com/t5/exchange-team-blog/basic-auth-and-exchange-online-february-20...

 

"To view Basic Auth connections today you should select everything except 'Browser' and 'Mobile Apps and Desktop Clients'. When non-browser clients are using Modern Auth they will be placed into the Mobile Apps and Desktop Clients group."

 

 

Brass Contributor

Hi

 

We also have legacy auth in the AAD sign-ins for lync.exe for one of our client ad for almost all their users.

 

S4b is on-prem (not sure if in hybrid mode yet) + Mailboxes in Exchange Online (hybrid mode with a few service mailboxes on the on-prem Exchange server) + ADFS for authentication.

 

We want to enable MFA using Conditional access policies but we first need to get rid of these legacy authentications from lync.exe.

 

Anybody can confirm that going through the following procedure will enable Modern Auth for lync.exe without impacting the services?
https://docs.microsoft.com/en-us/microsoft-365/enterprise/configure-skype-for-business-for-hybrid-mo...

 

Anything else to consider?

 

Thank you for you help.

Version history
Last update:
‎Jul 24 2020 01:42 AM
Updated by: