Azure AD: You Should Disable This Legacy MFA Setting

When talking with organizations about securing their Azure AD tenants, there is always a focus on the latest and greatest, and all the ways it brings everyone forward on the Zero Trust journey. Advancements in Conditional Access, Windows Hello for Business, FIDO2 – the focus is on what’s new and where to go. Occasionally there is the reminder to block legacy authentication (speaking of – have you?), but the focus tends to be on what’s new, and not reviewing what’s old.

There is one setting, however, that tends to lurk deep within Azure AD tenants, especially for organizations that have had their tenant for a long while, that goes unnoticed, and when left enabled, allows users to potentially interfere with what we believe to be their authentication pattern.

What’s the setting?

If we dig into the legacy multi-factor authentication service settings portal, which can be found by browsing to Azure AD -> Security -> MFA, and then on the right, under Configure, select Additional cloud-based MFA settings. It will bring you to the following:

The setting we are focused on is at the bottom. Under remember multi-factor authentication on trusted device, Allow users to remember multi-factor authentication on devices they trust.

What’s the problem?

The name of the setting doesn’t really explain it well. The Microsoft Docs article that explains the details of this setting can be found here, Configure Azure AD Multi-Factor Authentication – Azure Active Directory | Microsoft Docs.

Even though there is an additional note provided, a lot of organizations don’t even recall this setting exists – either they have never had to come to this set of options to begin with, or it was enabled several years ago and never reviewed again. Unfortunately, this setting is not well exposed in Azure AD.

When enabled in an Azure AD tenant, it allows end-users to make the decision on what a “trusted device” is. The heading for the setting, when glanced over, may make you believe it relates to trusted devices, as in compliant devices. But as we see within the details, the user is making that trust decision.

And the issue with that trust decision, is that it allows the user to choose to drop an MFA persistence cookie, completely separate from the refresh token, in the browser.

So even if our user chooses to sign-out, and even if they choose in the browser the option to forget their username from the sign-in menu, this cookie persists.

The user experience, with this setting enabled, will show the following during sign-in:

When enabled, the Don’t ask again for 90 days (or whatever interval is set in your organization) shows up and is checked by default.

On subsequent user sign-in, the user will not be prompted for MFA, unless the time specified in the setting has lapsed, or the browser cookies have been cleared.

You will see the following in the Sign-in details:

This setting is not the same as the Keep Me Signed In (KMSI) settings in Azure AD, which allow the user to retain their refresh token in their browser when they close it. The KMSI experience invalidates the token during user sign-out, and upon sign-in provides the expected behavior of calling for both primary authentication and MFA (if there is an MFA requirement).

Why exactly is this a problem

While it may be alluded to above, this setting weakens the security posture regarding MFA. It allows users to subvert when we may be requiring Conditional Access to call for MFA. Now we are not saying our user is doing anything malicious – this is a setting we enable and it’s logical that a user would select this. Users will pick whatever options make getting the job done with the least amount of friction.

If the device is or becomes compromised, the user account will become an easier target to malicious actors. Just think of any device you have the least amount of trust in, which usually is some sort of shared device outside the corporate boundaries, and then allow the user to make the trust decision. It’s not a great recipe.

Determining the Usage

If you’ve looked at your settings, and you see that this setting is disabled, then you can just stop here.

If you’ve found that this setting is enabled, you want to understand how widespread the usage is before disabling it. The fewer users leveraging it, the swifter the change process.

We want to explore our Azure AD Sign-in logs, however, we cannot filter granularly within the portal.

Using Log Analytics, the following query will help show who, where they are coming from, and the device information. The query is written to highlight distinct devices:

SigninLogs
| where TimeGenerated > ago(30d) //Set time period to within the last 30 days
| where Status.additionalDetails == "MFA requirement skipped due to remembered device" //String to search for
| project UserPrincipalName,IPAddress,OS = tostring(DeviceDetail.operatingSystem),Browser = tostring(DeviceDetail.browser),City = tostring(LocationDetails.city),State = tostring(LocationDetails.state),Country = tostring(LocationDetails.countryOrRegion) //Pull JSON data into strings
| distinct UserPrincipalName,IPAddress,OS,Browser,City,State,Country //Filter for distinct instances

If you do not have access to Log Analytics, you can export your Azure AD Sign-in logs in either CSV or JSON format and parse the data out accordingly, the string you will want to search for is MFA requirement skipped due to remembered device.

Remediation

I’ll preface that I’ve had dozens of organizations disable this setting with little notice to end-users, and with little disruption to their lives. Many of those organizations did not even search their logs prior to disabling it.

This only impacts browser sessions. Client applications will never present this prompt, regardless of whether the client application is on a mobile device or Windows.

If we are using Windows Hello for Business, FIDO2 security keys, or Authenticator App for Primary Auth, all those mechanisms provide for strong-authentication within them, and are not impacted by this setting.

For Azure AD Joined (AADJ) or Hybrid Azure AD Joined (HAADJ) devices, even if our users are using passwords and are requested to perform MFA, their PRT will obtain an MFA claim within it during the first run, and users will not be frequently prompted for MFA subsequently.

That’s a long way of saying the impact is usually limited to web browsers on personal devices that have no relationship to the Azure AD tenant. The devices we trust the least.

Once comfortable with turning off this setting, it’s simply a matter of unchecking the box in the MFA service settings portal we examined above.

If you want to limit MFA lifetime

I’ve encountered some organizations who have this setting enabled and the number dialed way down. When talking about corporate devices or devices we have insight into, through either MDM, MAM, hybrid trust, or such, it’s not recommended to limit MFA lifetime. We already have a level of trust established and prompting users frequently for MFA will not only create friction in the user experience, as well as sets our users up to be both more susceptible to MFA phishing (you get trained to just perform MFA without thought) as well as devise ways around security.

If you have business scenarios that call for the desire to prompt more frequently for MFA, Conditional access offers Sign-in frequency session controls as well as Persistent browser session controls, which can be targeted to non-corporate managed devices. Authentication context also allows for scenarios where we want to call for strong authentication scenarios when users are accessing sensitive information. These settings offer a higher level of precision to target certain scenarios while not negatively impacting the broader user experience.

Final Notes

This setting really has been a carryover from when we didn’t have the power available from Conditional Access, and unfortunately, it’s well hidden in that dusty MFA settings portal almost nobody ever treks into. Lucky for us, it’s a quick win in the name of security to disable.

About This Posts Featured Image

The chosen photo is the work of Michael Dziedzic, used under the Unsplash license.

Finding the proper image for this was a bit of work within the realm of free images, but after some pondering it works well enough. I was searching for an image of something important, such as the key, that could easily be overlooked when lost among other things.