Azure AD: New Controls for Authentication Strength

The Require authentication strength Conditional Access Grant Control is currently in Public Preview

Microsoft has released a much asked for setting, which also aligns to the Whitehouse memorandum, M-22-09, calling for federal agencies to require phishing resistant MFA by 2024, you can read the full memorandum here, M-22-09 Federal Zero Trust Strategy (whitehouse.gov).

With this, we now have granularity in Conditional Access to not just specify whether MFA is required, but also how strong the collective authentication is.

The Prior State of Azure AD MFA

Within the Grant Control section of a Conditional Access policy, we’ve always had the Require multifactor authentication control, which enforced MFA. But up until now, we never had the ability to specify what that level could be – if a user in a tenant has a FIDO2 security key, but also is registered for SMS text, they could use either that security key or their password and SMS text for MFA. In many tenants it’s always practical to try and restrict users from using weaker forms of MFA, especially at times when they may need to use that to bootstrap themselves into stronger authentication methods such as passwordless. And since this is a tenant-wide setting, we have had the historical issue where we couldn’t say enforce stronger forms of authentication for privileged accounts, such as Global Admins.

Require Authentication Strength

We also have the ability to define custom authentications strengths in Azure AD, which we can find under Security -> Authentication Methods -> Authentication Strengths (Preview).

And if we look at the details, this opens up a whole world of options for us:

First, let us examine the out-of-the-box options.

Multifactor authentication

The lowest denominator for MFA, this setting should be parity to the Require multifactor authentication setting that we’ve had available for as long as Conditional Access has existed.

We can examine this by changing an existing policy from Require multifactor authentication to Require authentication strength and selecting Multifactor authentication.

As a baseline, lets first look at what our Azure AD logs show us in the current state, with Require multifactor authentication enabled:

And if we look at the Conditional Access Policy details:

Now let’s change our policy to use the require authentication strength setting with multifactor authentication selected:

Require multifactor authentication and Require authentication strength are mutually exclusive, as they both enforce multifactor. Enabling one will disable the ability to use the other within the same Conditional Access Policy.

After we authenticate, the sign-in log looks the same:

However, if we examine the Conditional Access Policy details, we will see that we are satisfying for the new authentication strength grant control:

Passwordless Multifactor Authentication

Let’s kick the strength of the Conditional Access policy up:

With things turned up, let’s first look at the behavior if we attempt to authenticate with a password anyway.

Remember that Conditional Access evaluates after primary authentication, so our policies will not prevent a user from still attempting to perform password authentication.

First, entering our username and password:

We are then presented with another dialog, telling us that our organization requires additional sign in methods to access this resource:

Now if we take a look at our Sign-in logs, we’ll see that the initial username/password auth occurs, as well as passwordless to satisfy MFA requirements:

Microsoft does not consider Microsoft Authenticator passwordless (phone sign-in) as phishing-resistant. Because of this, the Passwordless MFA setting really does not seem to have any advantage over push notifications for MFA with number matching enabled.

Now if we repeat this process, and instead use something like Microsoft Authenticator for passwordless (phone sign-in), we will go right into our application:

And what happens if our user does not have a FIDO2 security key, is not on a machine with Windows Hello for Business, and does not have Microsoft Authenticator passwordless (phone sign-in) enabled?

If the authentication strength policy is applied to all resources, the user will get stuck in an endless loop of trying to enroll a stronger form of authentication:

Now this behavior, from a security standpoint, is not necessarily bad. However, from an end-user perspective it’s something to watch out for.

If you’re using a Temporary Access Passs (TAP) and accessing https://aka.ms/mysecurityinfo to enroll in strong authentication, that does satisfy the policy.

Phishing-resistant Multifactor Authentication

Finally, we’ll turn the dial all the way up, to phishing-resistant MFA:

Using our FIDO2 security key, we are able to access our resources without issue:

And if we attempt to use our password:

We are prompted to use a security key:

Now if our user doesn’t have a FIDO2 security key enrolled or is not accessing the resource from a device using Windows Hello for Business, they again will get stuck in an endless enrollment loop if the policy is applied to all resources.

Windows Hello for Business, FIDO2 security keys, and certificate-based authentication are the only mechanisms considered phishing-resistant within Azure AD.

Some Odd Behavior

In my testing, I happened upon that require authentication strength does not seem to play well with other grant controls. My test policy had been configured previously to Require one of the selected controls, effectively an OR situation, between Require multifactor authentication or Require device to be marked as compliant:

When testing, and switching to use this new setting, I found that the policy effectively turned into a device compliance required policy – before even being able to attempt MFA, I was presented with an error due to lack of device compliance:

I’ve reached out to Microsoft about this behavior, but it just leaves a bit of a cautionary tale to ensure that you selectively test who you are applying these policy changes to. When I find out more information, I’ll update this article. While this one specific case could be worked around by excluding compliant devices as a condition instead of a control, many organizations may still be using device compliance grant controls due to the feature having existed longer.

Final Thoughts and Notes

With this new setting for granular control of authentication strength, we can finally do things in our tenant such as (only a few initial thoughts):

• Require privileged users to have to use a phishing-resistant form of MFA
• In organizations such as higher-ed, restrict faculty and staff to stronger authentication while allowing students to continue to use weaker forms of MFA (as it required many times)
• Potentially have other avenues to restrict the ability to enroll other forms of MFA only from strong forms of MFA

Because this is only limiting the options used during authentication, this will not prevent a privileged user from enrolling in a weaker form of MFA, such as SMS. They’ll just never necessarily be permitted to leverage that.

Also, as I’ve found in testing, you’ll want to test these new settings thoroughly, to ensure that you aren’t creating scenarios for your end users where they can’t enroll in stronger authentication, and subsequently get stuck in a proof-up loop. Applying this new grant control across all users, for all applications, is likely too broad of a policy for the majority of organizations, unless you are certain about your existing passwordless usage. There’s nothing like a few hiccups with an authentication change in an organization to completely stall any progress.

I still have more testing I want to do – exploring what this looks like with external users and cross-tenant access settings. And there is the ability to create custom authentication strengths as well, which is ripe with granularity for all sorts of custom authentication strength. In all the testing of the different permutations, and a few setbacks from unexpected behavior, this article took longer than initially thought to craft.

End of the day, this is still a great step forward to ensuring that strong authentication is used when it matters within tenants. Can’t wait to see Global Admins voluntarily applying these policies to themselves. Just don’t forget to exclude those break-glass accounts ?.

About This Posts Featured Image

The chosen photo is the work of Brock Wegner, used under the Unsplash license.