Microsoft Secure Tech Accelerator
Apr 03 2024, 07:00 AM - 11:00 AM (PDT)
Microsoft Tech Community
New tools to block legacy authentication in your organization
Published Mar 12 2020 11:30 AM 160K Views
Microsoft

Hey folks,

 

If you’re a regular reader of this blog series, you know we’ve been advocating for admins to enable multi-factor authentication (MFA) for a while. In one of my previous posts, Your Pa$$word doesn’t matter, I showed how vulnerable passwords are to attack and why enabling MFA reduces the likelihood of being compromised by more than 99.9 percent.

 

For MFA to be effective, you also need to block legacy authentication. This is because legacy authentication protocols like POP, SMTP, IMAP, and MAPI can’t enforce MFA, making them preferred entry points for adversaries attacking your organization. In September 2019, Exchange Online announced the deprecation of legacy authentication prior to its removal on October 13, 2020. For more on the impact of legacy auth, and how we weaned Microsoft users off of it, check out the talk Lee Walker and I gave at RSA a few weeks ago.

 

The numbers on legacy authentication from an analysis of Azure Active Directory (Azure AD) traffic are stark:

  • More than 99 percent of password spray attacks use legacy authentication protocols
  • More than 97 percent of credential stuffing attacks use legacy authentication
  • Azure AD accounts in organizations that have disabled legacy authentication experience 67 percent fewer compromises than those where legacy authentication is enabled

LegacyAuth.jpg

 

Disabling legacy authentication for users is a must-do on your identity security checklist. In this blog post, I’ve asked Daniel Wood, a PM on the Identity Protection team, to walk through all the steps you need to take to secure your organization and introduce three changes we’ve made in Azure AD to make your job easier.

 

As always, we’d love to hear your thoughts! Ping me on Twitter (@alex_t_weinert) and stay safe out there.

 

Hey everyone!

 

As one of the PMs on the Identity Protection team, I’m going to walk you through a step-by-step guide to blocking legacy authentication in your organization. But first, I’m excited to announce three new capabilities our team has released to make the job easier.

 

  1. The sign-in logs are now available in the Azure portal to all tenants for 7 days
  2. The sign-in logs now include the user agent used to sign in
    legauth1update.png
  3.  The sign-in logs client apps filter now includes all legacy Exchange Online protocols
    legacy auth update pic.png

Blocking legacy authentication in your organization requires the right data. We worked with our customers and built the tools they asked for to give them the insights they need. The changes we’re announcing today will give all of you even more data about legacy authentication usage in your organization, so you can turn it off systematically and get the full benefits of protecting your organization with MFA.

 

Step 1: Understanding legacy authentication usage in your organization

The first place to look when identifying legacy authentication usage in your organization is the Azure AD Sign-ins page, which is now available in the Azure portal to all tenants for 7 days. The sign-in logs provide a wealth of information, including user, application, client app, device—and now—user agent. Filtering by client app will let you identify sign-ins by modern and legacy authentication. Client apps, including Browser or Mobile Apps and Desktop clients, are considered modern authentication, while the others, such as IMAP, POP, and MAPI are considered legacy authentication. 

 

legauth3.JPG

 

Larger customers will need to aggregate this data into a report or analyze the data using queries to fully understand patterns of legacy authentication usage. There are many ways to do this using Azure Monitor (with Azure AD Workbooks or Log Analytics), Excel, Microsoft Graph API, or a SIEM system.

 

Aggregating reports in Azure AD Workbooks and Log Analytics using Azure Monitor

We recommend streaming your sign-ins to Azure Monitor for real-time reporting and aggregation using Azure AD Workbooks and Log Analytics. Azure Monitor makes it easy to set the retention period and even set a daily cap on the amount of data stored.

 

Once your sign-ins are streaming to Azure Monitor, navigate to the Workbooks tab in Azure AD and open the new Sign-ins using Legacy Auth workbook. Here you will see information about which client apps are being used in your organization.

 

legauth4.png

 

Using Kusto Query Language (KQL), you can write your own queries to create custom reports using Azure Log Analytics. In Azure AD, simply click Logs to begin writing your own queries.

 

legauth5.png

 

Downloading sign-ins to Excel in JSON or CSV format

To download the sign-ins to JSON or CSV format, click on the Download button at the top of the Sign-ins page. If you filter the sign-ins by certain client apps, your download will be based on the filter selections you’ve made. We recommend downloading to JSON because this format includes all the sign-in details, including user agent. The CSV format will only show the top-level information in each row of the sign-in logs.

 

legauth6.png

 

You can then open a JSON file in Excel using the Get Data function.

legauth7.png

 

Using the Microsoft Graph API to get sign-ins

If you need to download more than 250,000 sign-in records, you can do so using the audit logs API in Microsoft Graph.

 

Step 2: Create Conditional Access policies in report-only mode

Once you’ve identified legacy authentication usage patterns in your organization, it’s time to start blocking legacy authentication. In most organizations, you can’t block legacy authentication for everyone right away. We recommend starting by blocking legacy authentication for only the group of users that don’t use it. As you make progress upgrading to modern authentication and disabling legacy authentication, you can expand the list of users in the group.

 

The easiest way to monitor the impact of blocking legacy authentication without disrupting users is using Conditional Access report-only mode. Policies in report-only mode are evaluated at sign-in, but the grant controls are not enforced, so you can see who is using legacy authentication in real time without blocking them. Start by creating a report-only policy that blocks legacy authentication for everyone in your organization. Remember that Conditional Access policies do not apply to legacy authentication clients by default, so you need to explicitly scope your policy to block client apps that are not Browser or Modern authentication clients (i.e. legacy authentication clients). Let the policy run for a few days to get the most accurate reflection of legacy authentication usage in your organization.

 

legauth8.png

 

You can determine how many users will be blocked by the policy by using the new Conditional Access Insights workbook and selecting your policy in the Conditional Access policy filter. To access this workbook (after you have integrated your sign-in logs with Azure Monitor), navigate to the Workbook blade and select Conditional Access Insights. Clicking on a tile such as Failure will filter the dashboard by those users that would be blocked by the policy. Create an exclusion group and add any users for whom you are not quite ready to block legacy authentication.

 

legauth9.png

 

Step 3: Blocking legacy authentication in your organization

 

Blocking legacy authentication using Azure AD Conditional Access

Once you have monitored your policy in report-only mode for a few days and you understand the impact of the policy, you’re ready to start blocking legacy authentication. The easiest approach is changing the state of the policy from Report-only to On. Alternatively, if you want to continue monitoring the impact of blocking legacy authentication in report-only mode for users that aren’t ready yet, you can create a separate Conditional Access policy that enforces blocking legacy authentication for the users that you identified in Step 2.

 

Blocking legacy authentication service-side

In addition to Conditional Access, you can also block legacy authentication service-side or resource-side (versus at the authentication platform). For example, in Exchange Online, you could disable POP3 or IMAP4 for the user. The problem with this is you do not want to block protocols that can do legacy and modern authentication (i.e. EWS, MAPI) as you may still need them. To help with this, Exchange Online released a feature called authentication policies, which you can use to block legacy authentication per protocol for specific users or for the entire organization. The protocol connection is denied before checking credentials against Azure AD or ADFS, so the enforcement is done pre-authentication.

 

Hopefully, this blog post has given you all the information you need to get started with blocking legacy authentication in your organization. For any questions, you can reply to this blog post in the comments below, send an email to our team (intelligentaccesspm@microsoft.com), or reach out to Alex (@alex_t_weinert) and me (@daniel_e_wood) on Twitter.

 

Thanks!

Daniel

 

21 Comments
Copper Contributor

Hy @Alex Weinert  thanks for this Post. In my opinion one authentication type is missing in the aggregated report, its "Exchange Active Sync". Also in your Step1 picture the protocol is not filtered. Isn't it that EAS also used basic authentication and needs to be disabled by using Outlook App or for example Apples native iOS App > 11.0 which uses modern Authentication by oAuth 2.0 support.

Microsoft

Hi @Daniel Nitz, thanks for reading and I'm happy to address your comments to the blog post. 

 

The aggregated report shows all legacy auth protocols used, including Exchange ActiveSync, but a protocol does not get listed if there are no sign-ins of that type. Since there were no sign-ins using Exchange ActiveSync in the time range specified (14 days), Exchange ActiveSync does not appear in the Sign-ins using Legacy Auth workbook. 

 

The screenshot in Step 1 is filtered to include 14 client apps. You can see whether a filter is applied where it says Client app: 14 selected. 

 

As the blog mentions, there are two ways you can block legacy authentication. The first way is via Conditional Access, and the second way (which you mention in your comment) is to disable the protocol at the service level. 

 

Thanks,

Daniel Wood

Copper Contributor

Hi Daniel,

 

many thanks for your response!! I noticed that even if I have many Exchange Active Sync logons, this logon type does not come up. For example in a customer tenant I have following situation. 

I can see lot of sign ins using EAS

 

2020-03-19_20-10-38.png

 

But the Report doesn't show the Active Sync Protocol.

 

2020-03-19_20-12-03.png

 

The query shows me that Exchange Active Sync is filtered out

 

2020-03-19_20-16-41.png

 

So a problem in the query?

Microsoft

Hi @Daniel Nitz--thanks for your observation. Indeed you are correct--we were inadvertently filtering out Exchange ActiveSync in the workbook query. That will be corrected soon. 

Copper Contributor

In addition to this, the Microsoft documentation on setting up Conditional Access to block legacy authentication does not appear to consider ActiveSync a legacy authentication protocol:

 

https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/block-legacy-authenticati...

 

Further, the instructions on that page for setting up the policy clearly exclude Exchange ActiveSync clients from the block.

Microsoft

Hi @mromp-bdo, thanks for your comment. We will update our guidance in the doc. Legacy Exchange ActiveSync will be deprecated in October as announced by the Exchange team earlier this year, so it should be blocked by organizations if possible. 

Copper Contributor

For conditional access, I'm attempting to setup a legacy authentication block. I do not have any option to set conditions. Is this a limitation of Azure P1? @danielwood95 

 

secDM_0-1587495841826.png

 

Microsoft

Hi there, what licensing skew do you have? Conditional Access requires Azure AD P1/EMS E3/M365 E3 licensing. If you are able to create a Conditional Access policy though, you should not be restricted in which conditions you can configure. The screenshot you've posted shows unexpected behavior, so I will follow up with you individually to get some more details. 

Iron Contributor

Just curious if anyone has noticed this oddity.

 

We disable IMAP and POP on every mailbox within our tenant. We don't use MFA and are slowing transitioning away from legacy auth. In my report(s) I see numerous entries for authentication attempts from varying parts of the world using IMAP. I opened a support ticket with the (not so) fine folks at Azure Active Directory support and just wasted multiple days running in circles (language/comprehension disconnect). I learned merely a few hours ago, the support/ticket system is specific to "code red", "may day", "system down" triage and root cause type support and not "why does my report show me inaccurate information?" type support.

 

So, my question is this. If IMAP is disabled, why does my sign-ins report indicate someone from Brazil, Vietnam, etc., attempted to sign in to a licensed user's mailbox and failed due to the use of an "incorrect password"? The client app column indicates IMAP is/was used. That said, which is incorrect, the column or my concern (understanding) that IMAP isn't really disabled? Please note: Yes, IMAP is disabled on every mailbox. I am the only global admin for the tenant and I double-checked every mailbox in question before posting this.  :0)

Brass Contributor

@lance-aughey Hey I just had the same experience yesterday and finally figured it out (based on a few other websites).

 

Disabling the protocol/service is not the same as authentication. Yes you've disabled the IMAP protocol on the mailbox but you haven't blocked it at the authentication stage. To do this you need to use either CA or Authentication Policies (or both). Check out this MS Doc for Authentication Policies and blocking legacy auths.

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

You can apply it at the entire org level or to individual users.

Steel Contributor

Hi @Alex Weinert   

Can you enlighten me? - why is the 'Common Data Service' listed as using Legacy Auth. under 'Insights and Reporting'  in CA? (I've created "Block Legacy Auth." and running this in Reporting mode)

Also in the 'Identity Protection' it's listed as Legacy Auth. Sign In?

Copper Contributor

We are using ActiveSync with Certifcate based Authentication on our Mobile Devices. This is still working after we set AllowBasicAuthActiveSync=false for all of our users.

 

Workbook "Sign-ins using Legacy Authentication" shows this Sign-ins as legacy as it does not exclude AuthenticationDetails -> authenticationMethod = "Certificate"

 

Does this Workbook just not consider this scenario or will Active Sync unsing CBA be disabled in the future?

Microsoft

Hi @FabianSeither good question. The workbook does not consider this scenario. Thanks for pointing this out. 

Copper Contributor

But ActiveSync using CBA will still be supported in the future?

Copper Contributor

Is ActiveSync using CBA is still supported?

 

If ActiveSyn is considered legacy, What is the latest recommended authentication for Mobile Devices for exchange on prem

Copper Contributor

Two years after this post I am just now finding it as I try to make sure all our legacy auth is blocked. The security center scorecard keeps warning me telling me to update my clients, but when it comes to attackers, I can't just ask them to please update to modern authentication. As a smaller organization with maximum security being very important, where's the checkbox to just disable all legacy/insecure access for my organization? I have to learn a new query language I've never heard of? How was this ever considered acceptable? With an on-prem Exchange server I could just disable legacy protocols on the server, block the ports on my firewall, and call it a day. I keep digging deeper and deeper into this rabbit hole and every single recommendation is followed up with 'but you'll need to do THIS after you've done that'. Set a policy for existing users, but you have to set another policy for new users, but that's still only going to cover users but not the organization as a whole. HOW is this considered acceptable from a company that is supposed to have shifted its focus to improved security? I found this wonderful document: https://docs.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/deprecation-of-basic... stating that MS was going to start disabling legacy auth for customers *who don't use it* and giving them the option to *opt out*. What I want to know is how can I opt IN? Just make my life easier and disable all this legacy insecure garbage.

Copper Contributor

@Mike_Saulters It looks like the setting "Enable Security defaults" in azure might be what you are looking for.

 

"Security defaults is a set of basic identity security mechanisms recommended by Microsoft. When enabled, these recommendations will be automatically enforced in your organization"

 

"If you've enabled security defaults in your organization, Basic authentication is already disabled in Exchange Online."

Copper Contributor

RE: 3. The sign-in logs client apps filter now includes all legacy Exchange Online protocols

 

To see this, choose "Client App" then you can choose Modern or Legacy Authentication Clients.

 

Iron Contributor

@Mike_Saulters So glad I'm not the only one drowning in all of this. Among my many, many other responsibilities, been attempting to implement this B-2-M transition for many years. For us, the suggestion to "simply use security defaults" is, to put it bluntly, irresponsible. So many changes, updates and many problems coming out of the woodwork has me breathing a sigh of relief that we didn't go that route.

 

@Alex Weinert @danielwood95 I've gone through our 3 tenants (don't ask, my response/answer will further angrivate me, LOL) and have all licensed humans assigned to one of 4 authentication policies:

 

Block Basic <-- Modern ONLY

Allow EAS OutlookService and SMTP <-- a few MacOS users with native Apple and 3rd party email clients

Allow EAS <-- many iPhone users with Apple Mail/EAS

Allow SMTP <-- LOB/IOT devices

 

The following "names" (get-user | ft Name, Auth*) remain without a particular policy (I.e., blank). Please shed light on what to do, if anything, with these IDs/objects. I've scoured the many available resources and can't locate anything specific about them...either no consideration has been made or it's in every resource I've reviewed (and am too blind to see it).

 

user_domain.tld#EXT# -- external user (mostly identities from our other tenants, but we have a few "true" external individuals)

"Shared" Mailbox without an Exchange License -- Public Folder replacement (we do not use Teams)

"Generic" Mailbox with an Exchange License -- shared department/service responsibilities (e.g., HR, Finance, etc.) and additional capabilities (e.g., flows, storage, management, etc.).

DiscoverySearchMailbox{...} -- I've learned (and forgotten) what this is for (far too many times to count).

 

Thank you, in advance, for direction/insight.

Brass Contributor

Jack_Chen1780_0-1660941253934.png

I am wondering if someone can help me to understand the workbook. When I search sign-in log with all 13 legacy apps, it showed 0 result. But if I run the workbook, it showed some result:

 

Jack_Chen1780_1-1660941420069.png

Jack_Chen1780_2-1660941532213.png

How come there are legacy authentication with Azure portal?

Brass Contributor

This was really helpful, thank you. Can you provide a bit more detail on what "autodiscover" is as it relates to this conversation?  

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