Legacy authentication (or just legacy auth for short) is something that each organization should ensure is no longer used. It’s a vast topic with several ramifications and things to consider. In this article, I’ll focus on disabling and cleaning legacy auth attempts from your services and users in the cloud. On-premises is left for another post.
What is legacy auth?
The usual meaning for legacy auth in the context of Microsoft Cloud services includes all those older protocols one could use to access email and other services: SMTP, IMAP, POP, etc. These have been replaced long ago with more modern authentication services. More importantly, modern authentication supports and can enforce multi-factor authentication (MFA), often a driver for blocking legacy authentication altogether.
The reason these old legacy auth protocols are still needed is often older apps and devices. I’ve witnessed modern phones such as iPhones having installed old apps that access your email and calendar using legacy auth – despite these phones having native or readily available modern apps supporting modern auth and MFA. Often, this is because a user is accustomed to using a specific app and doesn’t think twice whether or not the app is suitable for use in 2021.
Microsoft has a list of all the legacy auth protocols, including quite a bit of capability – Exchange Web Services, MAPI over HTTP, and Offline Address Book, to reference a few.
What’s the risk?
In essence, legacy auth is a security risk for many reasons, and organizations should strive to disable using these in the future. One of the main risks is that an insecure legacy auth protocol might expose credentials and other secrets. The other reason is that legacy auth cannot enforce MFA – and thus, in turn, makes it hard for an organization to embrace proper security policies. Users sometimes reuse passwords between different services, which also puts your cloud-based identities at risk if the same password is used elsewhere and gets exposed.
Detecting if legacy auth is being used
Before we block legacy auth, knowing how widely it’s still used is helpful. There’s an easy way for this now within Azure Portal. Navigate to Azure AD > Sign-ins, and from the top toolbar, select Add Filters, and as filters, add Client App.
Now you can select the client apps you want to filter on, and Microsoft has made this easy: Select all the legacy ones – 13 in total:
Note: Set the timescale to 1 month to generate enough log entries for further analysis.
Depending on your organization, this might produce a long list of sign-ins. It’s crucial to go these through and try to identify patterns: Are you seeing just one or two users continuously utilizing legacy auth, or is it more random? To make this even easier, click Download > Download CSV from the top-most toolbar, then select InteractiveSigns_<YYYY-MM-DD-YYYY-MM-DD>, the first on the list.
Note: My friend Joosua correctly pointed out that you must also download the Non-interactive CSV files to ensure that additional sign-ins using legacy auth are being done there!
Next, open Excel, select Data > From Text/CSV, and locate the downloaded CSV file. The most valuable columns are the username, the used Application, Status, Failure reason, and Client app. The Operating System column gives more clues about what’s happening in specific scenarios. Here’s a view with a subset of these columns:
We can see that a few users have used an iPhone with iOS to log in via Exchange Web Services using legacy auth. Another user has used an Android device, and the accounts are now locked – perhaps due to an incorrect password having been used. There is one success for SMTP, which is interesting – who needs to use this, and why?
I’ve also seen entries in the sign-in logs for automation that do not expose the client app or the OS. The best clue is then the user account to investigate further.
Based on the findings, you can now decide what to do.
Options for dealing with legacy authentication
Once you’re confident that users have alternate – more modern – ways to deal with legacy auth no longer being available, you can directly block it with Azure AD’s Conditional Access:
However, please note that Azure AD Conditional Access requires each user's Azure AD Premium P1 license. A blanket block is most easily achieved with this feature; you can do exclusions as needed later on.
Another way is to indirectly block legacy auth by requiring MFA (and thus, more modern authentication requests) through each service – perhaps by utilizing Conditional Access.
Additional resources
More time and effort go into figuring out who is still using legacy auth and how to support users for more modern authentication models than just blocking these requests. There are a lot of other aspects to consider, such as SharePoint Online, so I’ve gathered additional resources here for your convenience:
- Using Conditional Access in report-only mode
- Modern auth with Office client apps
- Ensure modern auth is enabled (for any Azure AD tenants provisioned since August 1, 2017, it is enabled by default)
- Streaming Azure AD sign-in logs to Azure Monitor for easier reporting
