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 how to disable and clean 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, and such. These have been replaced long ago with more modern authentication services. And more importantly, modern authentication supports and can enforce multi-factor authentication (MFA), which is often a driver for blocking legacy authentication altogether.
The reason these old legacy auth protocols are still needed is often older apps and/or devices. I’ve witnessed modern phones such as iPhones having had old apps installed 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, and it includes quite a bit of capability – Exchange Web Services, MAPI over HTTP, Offline Address Book, just to reference a few.
What’s the risk?
In essence, legacy auth is a security risk for a multitude of reasons, and organizations should strive to disable the use of 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, and this puts your cloud-based identities at risk also, if the same password is used elsewhere and it gets exposed.
Detecting if legacy auth is being used
Before we actually get to block legacy auth, it’s useful to know how widely it’s still used. 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: Just select all the legacy ones – 13 in total:
Note: Remember to 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, and then select InteractiveSigns_<YYYY-MM-DD-YYYY-MM-DD>, the first on the list.
Note: My friend Joosua correctly pointed out that you also need to download the Non-interactive CSV files, to ensure if additional sign-ins using legacy auth are being done through there!
Next, open Excel and select Data > From Text/CSV, and locate the downloaded CSV-file. The most useful columns are the username, the used Application, Status, Failure reason, and Client app. In certain scenarios, the Operating System column also gives more clues as to what’s happening. 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 used 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 at all. 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 certain that users have an 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 an Azure AD Premium P1 license for each user. A blanket block is most easily achieved with this feature, and you can do exclusions as needed later on.
Another way is to indirectly block legacy auth by starting to require MFA (and thus, more modern authentication requests) through each service – perhaps by utilizing Conditional Access also.
Additional resources
More time and effort goes to 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
I work with Azure and frequently write about my experiences. I’m a Microsoft Most Valuable Professional, ex-MSFT. Based in Helsinki, Finland.