Microsoft’s new authentication strength options for Conditional Access is awesome, and I encourage you to start using this feature. This post will add some clarification on using Conditional Access for MFA, how to add a FIDO2 security key as an authentication method, and then how to use conditional access to protect certain applications with different levels of authentication strength.
Using Conditional Access for MFA
If you are still using Legacy Per-User MFA, you should be moving to conditional access. My post here explains how to easily do that. Keep in mind that app passwords will no longer work if you are still using them. However, you should be moving away from those if you’re still using them. One other note on this is to make sure you disable the verification options and “remember multi-factor authentication on trusted devices” in the service settings. These will conflict with the new authentication methods policies, and conditional access sign-in lifetime policies. You can find more details on that here – https://learn.microsoft.com/en-us/azure/active-directory/conditional-access/howto-conditional-access-session-lifetime. Make sure you disable these service setting after you disable per-user MFA and move to Conditional Access, otherwise, users may not be able to sign-in.
Here is a screenshot of the service settings with the options unchecked. We will configure these options under the new Authentication Methods Policies:
Configure your Authentication Policies:
Sign into entra.microsoft.com and navigate to Protect & Secure > Authentication Methods. Here is where we can enable the authentication methods we want to use for MFA. In this example, I will enable FIDO2 security Keys, the MS Authenticator App, and SMS for all users. You can enable specific methods for a subset of users if you need to.
Clicking on one of the methods will give you additional options. For Example, if we select the Microsoft Authenticator Method, and navigate to the configure Tab, we can configure the authenticator behavior. You have three options – Enabled, Disabled, or Microsoft Managed. Enabling will force the feature to be turned on. Microsoft managed will let Microsoft enable the features over time in the tenant. I chose to enable these settings for all users:
An Example of how this looks when someone signs in using authenticator can be seen below. We see the geographic location, app name, and we are required to type the number shown on the device signing in. This makes users think instead of blindly accepting a push request:
Adding a FIDO2 security Key:
FIDO2 security keys are among the strongest authentication methods available, and are identified by Microsoft as Phishing Resistant (WHfB and Certtificate Based authentication are the other phishing resistant methods). Users can add methods from mysignins.microsoft.com under the security tab. Currently, this account only has the authenticator as a sign in method:
Click Add sign-in method and select security key. I’ll be using a YubiKey 5 device.
Select your type of device device:
Click next
Click OK
Click OK
Insert USB security key:
Set a PIN for your device if prompted, or if you already set one, enter it:
Touch the security Key:
Name your security key when prompted, and click done
Now we have two authentication Methods. Microsoft Authenticator and a security Key:
Since we are also allowing SMS, we can Add another sign-in method and select phone to add SMS. SMS is better than nothing, but I recommend against using SMS. If you’re currently using it, try transitioning users to the Authenticator App. After adding more methods, you can change the default method if you’d like:
Using Conditional Access for MFA and setting authentication strength:
This part is rather simple. I’ll be making two policies. The first will require MFA for all users using any authentication method. The second will protect a specific app, Microsoft Teams in this example, with Phishing resistant MFA, which will require my account to use the security key. More on authentication strength can be found here – https://learn.microsoft.com/en-us/azure/active-directory/authentication/concept-authentication-strengths#built-in-authentication-strengths
A table from the above link is shown here with the authentication methods and their MFA strength:
MFA for all users policy:
This applies to all my users in my dev tenant. If you want to use a break glass account with a long complex password, you can exclude it from this policy. I’ll be applying this to all users and all apps:
Select the grant controls, and select “require authentication strength” to select which methods we want to enforce. For this policy we will select Multifactor Authentication, which allows any authentication method we have configured (SMS, Authenticator, or security key).
Save your policy. When a user signs in, they can choose which method they want to use if they want to use something other than their default:
Require phishing resistant MFA to access Teams
Next, we will configure the policy which requires stronger authentication for a specific app. We will use Teams in this example, and only apply it to specific users. I have this applied to my test user and we select Teams as an included app:
Next, we create our grant control to use authentication strength, and select Phishing-Resistant MFA, which requires a security key, WHfB, or certificate based auth:
If we try to sign directly into teams, or if we try accessing teams through the web app, we will be forced to authenticate with our FIDO2 security Key. Note that the current sign in was authenticated with the authenticator app, but since this specific app requires stronger authentication, we will be required to provide the security key when opening the app.
Here is a gif of the whole process in action from user signing into portal.office.com using the authenticator app, and then having to provide a security key when accessing Teams:
On a related note, I recommend reading this entire article if you need to configure sign in lifetime, persistent browser settings, or risk based authentication. Configure authentication session management – Azure Active Directory – Microsoft Entra | Microsoft Learn
Let’s look at the sign-in logs and see how they display for the sign-ins. Here is the sign-in to the Teams Web client, which requires phishing resistant MFA:
And the Authentication Details:
And the Conditional Access details:
Compared to a sign-in to the office portal, we can see our MFA for all users conditional access policy is required. The teams policy doesn’t kick in until the user tries accessing teams.
