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:
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.
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.
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.
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.
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.
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.
You can then open a JSON file in Excel using the Get Data function.
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.
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.
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.
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 (firstname.lastname@example.org), or reach out to Alex (@alex_t_weinert) and me (@daniel_e_wood) on Twitter.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.