Conditional Access Authentication Strengths – first thoughts

Howdy,
Long time no writing but I’m back on my track.

Today I’d like to share with you my thoughts regarding the recently published (in preview) conditional access feature called ‘Require authentication strength.’

You may remember my series regarding Passwordless Authentication and one mail feature that was missing – unable to configure CA policy to enforce FIDO2 keys usage for privileged accounts. Of course, we were able to choose Passwordless during the login process, but we were unable to enforce it to use passwordless only.

Finally, recently Microsoft announced Authentication strength – a feature that addresses this missing piece of the puzzle.

Solution Overview

Let’s talk about the solution itself – why it is a game changer and what it actually changes?

The answer is simple – It changes a lot – now we can control what type of authentication strength will be used for specific CA policies. In my mind, there are 3 examples at least:

• Enforcing standard MFA for users – we can use standard MFA apps like Microsoft Authenticator, SMS, call, and FIDO keys

• Enforcing Passwordless authentication for users with high privileges or VIP users. If we want to be more secure, we can choose the second option – here, we can either use Microsoft Authenticator in passwordless mode or FIDO2 keys.

• Enforcing the highest possible security level like FIDO2 keys or Windows Hello for Business usage for Global Admins and accounts like Break Glass Accounts. For security freaks and specific business needs, we have only two options – FIDO2 keys or Windows Hello for Business.

Sounds secure? Indeed it is. Let’s move on and start working on it.

Requirements

From a requirements perspective, you will need to have the following:

• Azure AD (test) environment
• Phone with MS Authenticator
• At least one FIDO2 key
• Windows Hello for Business solution implemented – we will skip this and focus on FIDO2 keys usage.

Test Accounts Preparation

Before we will go deep into the policy setup, we should prepare some test accounts.

In my case, I have created 3 test accounts:

• TestUser1 – for multifactor authentication case.
  This user has SMS configured as an MFA solution
• TestUSer2 – for passwordless multifactor authentication case.
  This user has MS Authenticator configured in passwordless mode.
• TestUser3 – for phishing-resistant multifactor authentication case
  This user has a FIDO2 key configured for the strongest authentication method.

It is important to set up the required accounts before playing with CA policies. It will prevent you from ‘booting loops’ during the account setup after enabling CA Policies.

To use a passwordless solution for TestUser2 and TestUser3, you must add them to the FIDO2 security key and Microsoft Authenticator authentication methods in Azure AD. This step was described during the series describing passwordless solutions in Azure AD.

Conditional Access Setup

To test Authentication strength settings, I have created 3 CA policies:

• Require Authentication Strength – MFA – targeted on TestUser1
• Require Authentication Strength – Pless MFA – – targeted on TestUser2
• Require Authentication Strength – PR MFA – – targeted on TestUser3

Below you can find CA policies configuration examples.

Tests

Require Authentication Strength – Multifactor Authentication

The first test would focus on accessing the Azure portal using the TestUser1 account

This was a standard login process we all know. Below You can find the results taken from the Sign-in Logs.

You may notice that on the Conditional Access Policy details page, Access controls are Satisfied for Require Authentication Strength – Multifactor Authentication, which means that we have passed the first test.

Require Authentication Strength – Passwordless Multifactor Authentication

Same as before, we are going to access the Azure portal but now, with the TestUser2 account.

Here you can see that I was using MS Authenticator working in passwordless mode ( I was asked to provide code to the application), which worked like a charm.

But how it looks from a logs perspective?

Again (surprisingly), everything was in the logs on the Conditional Access Policy details page, Access controls are Satisfied for Require Authentication Strength – Passwordless multifactor authentication, which means that we have passed the test.

Require Authentication Strength –Phishing-resistant Multifactor Authentication

The last test would be performed on the TestUser3 account accessing the Azure portal.

Based on the Conditional Access Policy details page logs, Access controls were Satisfied for Require Authentication Strength – Phishing-resistant multifactor authentication, which means that we have passed the last test.

Customizing Authentication Strengths

I can bet that some of you asked yourself, “Is it possible to create custom Authentication Strengths?”

The answer is YES; it’s possible

The video below shows the process of reviewing how authentication strengths are configured and how to create custom ones.

Conclusions

Without a doubt, Authentication Strength is a long-awaited (at least by me) functionality that was missing in the Conditional Access / Azure AD Identity Security. Now with this powerful feature, we can start rearranging our company policies and procedures to protect highly important accounts just by CA Policy configuration.

You may also notice that during the demo part, I was using the Microsoft Entra portal.
In the next weeks, there will be a dedicated series regarding this product, so stay tuned and secure!

I’d also like to thank Feitian Technologies Co., Ltd. for providing me test FIDO key for the test.