jussiroine.com Open in urlscan Pro
2a04:4e42:600::775  Public Scan

Form analysis
0 forms found in the DOM

Text Content

Jussi Roine
 * About me
 * Podcast
 * Contact me
 * Pi-hole adlists




DISCOVERING AND BLOCKING LEGACY AUTHENTICATION IN YOUR AZURE AND MICROSOFT 365
SUBSCRIPTIONS

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

JUSSI ROINE

Jan 19, 2021
Azure AD

← Previous

Next →
 * About me

©️ Jussi Roine <jussi@roine.fi>