Enforce Passwordless Authentication
Before Authentication Strength for Conditional Access was available, I explored Passwordless Authentication (including TAP) with focus on Security Keys for Windows.
In this post, I will focus on how to utilize Authentication Strength in Conditional Access to enforce Passwordless Authentication in Azure AD.
Configuring Authentication Strength in Conditional Access
To view existing configurations and create new ones, head to Authentication Strength
The default ones as of today are these three:
However the built-in Passwordless MFA does not allow TAP, which means that Passwordless onboarding of new users will be troublesome (with the requirement to become Passwordless, TAP is required for the initial onboarding into the setup of the Authenticator App).
Let’s create a custom authentication strength that adds TAP for successful onboarding. Important note: For onboarding of new users, TAP might need to be used twice (Authenticator login and then Passwordless step-up).
Name: Passwordless MFA + TAP
Type: Custom
Description: Passwordless methods for the strongest authentication, such as a FIDO2 security key including TAP
Authentication Flows
Windows Hello For Business OR FIDO2 Security Key OR Certificate Based Authentication (Multi-Factor) OR Microsoft Authenticator (Phone Sign-in) OR Temporary Access Pass (One-time use)
To utilize the newly created Authentication strength, create a Conditional Access policy.
Give it a suitable name (GRANT — Require Passwordless Authentication). In this example, I will target All Cloud Apps and in the Grant section, we will select “Require authentication strength” and choose our newly custom created “Passwordless MFA + TAP” as the control to grant access.
If the assigned users then authenticates with weaker authentication methods than those that are required, the end user meets this:
Viewing the Sign-in logs, the result of the control was as expected Failed:
Remember, if any of these configured methods for the policy are used, the result will be successful!
Authentication Flows
Windows Hello For Business OR FIDO2 Security Key OR Certificate Based Authentication (Multi-Factor) OR Microsoft Authenticator (Phone Sign-in) OR Temporary Access Pass (One-time use)
Additional layer of security, requiring Phishing-Resistant MFA
Another built-in authentication strength is the Phishing-Reistant MFA which consists of Windows Hello for Business, FIDO2 Security Key or CBA.
Name: Phishing-Resistant MFA
Type: Built-in
Description: Include authentication methods that are phishing-resistant like FIDO2 and Windows Hello for Business
Authentication Flows
Windows Hello For Business OR FIDO2 Security Key OR Certificate-based Authentication (Multifactor)
With the same methodology as before, we can create another Conditional Access policy to require an additional layer of security and here we could enforce the requirement on specific Cloud applications and/or for specific privileged roles. In this example, I will target the cloud application ‘Azure Management’. I also added the control ‘Require Compliant device’ in this specific Conditional Access policy.
Example name: GRANT — Require Phishing-Resistant MFA
Both of these Conditional Access policies with the different requirements are assigned to the same user.
GRANT — Require Passwordless Authentication
GRANT — Require Phishing-Resistant MFA
The user then navigates to https://portal.azure.com/ and during authentication multiple requirements will need to be met.
First, any of the required controls in GRANT — Require Passwordless Authentication are required, in this test Passwordless (Microsoft Authenticator) was good enough to fulfill that specific requirement.
Since we also require stronger authentication methods with GRANT — Require Phishing-Resistant MFA, the user also needs to use a security key for successful authentication. This would also be true if the user opens https://portal.azure.com/ in a new tab in the same browser session.
Viewing Details for Conditional Access in the Sign-in logs, both policies are were successfully applied!
Authentication Strength increases the capabilites for requiring stronger authentication methods. Another potential use case for it could be requiring it when accessing a Cloud PAW. Since Authentication strength is built on Conditional Access, it is very flexible in terms of what kind of cloud application, role or user type that need to comply with the requirements.