As we all know, passwords are a weak link in our identity processes. But, contrary to what we believe, your password length is not the main enemy when talking about Azure AD, as long as your passwords are not simple. Instead, the main enemy is that passwords can be easily gathered and reused from phishing attacks or breaches.
The most common attacks, for example, phishing, password spray and credential stuffing, all rely on the fact that your password is either given by the user to the attacker, guessed because it was really simple, or already exposed to attackers because of previous breaches in 3rd parties attacks. Also, in the case of password spray, Azure AD has functions in play to drastically reduce the speed of password spray attacks and increase the time attackers spend guessing a password.
Image from the Microsoft Docs
Regarding why your passwords mostly don’t matter, Alex Weinert, Director of Identity Security at Microsoft, wrote a wonderful article way back in 2019 that I suggest you read:
But, if you still need to start modernizing your application log-in processes, and most applications in your environment rely only on either Active Directory or Active Directory Federation Services, please still consider a more complex password. In this case, the standard is usually set at 15+ characters, as when a password is created of more than 14 characters, you don’t store the LM hash for it. Of course, you can also disable LM hashes with GPOs, but most places aren’t doing it.
The aim of this post, though, is to discuss Azure AD-connected systems, applications, and cloud-only environments.
If you haven’t heard of it, you can either natively attach most applications to Azure AD or use Azure AD Application Proxy. Azure AD Application Proxy allows Azure AD to take the reins by letting it manage the authentication and access to the on-premises legacy applications.
MFA does put a patch on the issue of passwords. For now, if everyone had (preferably strong) MFA on their accounts, the compromises would go way down, as the attackers’ costs would go way up. But, as we said, MFA is a patch, not a permanent fix.
For example, many companies still rely on legacy authentication methods, which do not support MFA, or there are cases where MFA gets “skipped” with the use of man-in-the-middle attacks (such as the ones that can be conducted using evilginx2). While it’s not really a “skip”, it’s functionally a bypass of MFA functions.
While passwordless methods are more secure and convenient, you should know that there is a better and worse ranking.
For example, adopting passwordless using the Microsoft Authenticator still puts you at risk of being phished with men-in-the-middle attacks, such as the ones we talked about before, and logging into Windows devices with the Authenticator is not supported at the moment.
Suppose you have a Conditional Access Policy that requires devices to be compliant. In that case, the Authenticator makes more sense as a passwordless method, as you add an additional layer of verification before accessing your company data.
Image taken from Microsoft Docs
Because FIDO2 Keys are not supported on mobile devices, the Microsoft Authenticator is still the best passwordless option for iOS and Android devices. It’s also a very common method for MacOS and Linux users.
As a side note, most of the time, instead of signing in with the Authenticator, on mobile you’ll be able to select “Sign-in options” and be presented with the option of signing in from another device, such as a desktop, where you’ll be able to use FIDO keys.
We’ll discuss the other two passwordless methods in the next chapter.
Windows Hello for Business and FIDO2 security keys
Windows Hello for Business and FIDO2 keys directly communicate with the service you are authenticating to. As such, they can only initiate the login flow if you are connected to the right page. And while this is already placing them up in the ranks, they can also provide access to Windows devices from the lock screen.
It’s worth noting that while Windows Hello for Business needs setup on every machine, FIDO2 keys can attach directly to the Azure AD user, making it way easier to use if the user is not always connected to the same device, as it happens with front-line workers. This happens because FIDO2 security keys store the credentials on the key, unlike Windows Hello for Business, where the key pair is bound to the TPM.
It’s also worth noting that Windows Hello for Business can (with some complex deployment options) also integrate with on-prem resources. One such use case is using Hello for Business with certificates to allow integration with the RDP protocol:
Here is a small table that recaps what methods are available, based on device type.
Device
AD FS or Azure AD native certificate-based authentication
FIDO2 security keys
Windows Hello for Business
Microsoft Authenticator with compliant device CAP
Windows device
iOS mobile device
Not applicable
Not applicable
Android mobile device
Not applicable
Not applicable
MacOS device
Edge/Chrome
Not applicable
While we are on the topic, you can configure users with a one-time-use Temporary Access Password to make users passwordless from day one, but the topic will be discussed further down.
A very useful page to plan your passwordless implementation is the following. It guides you through a wizard that proposes the best options for your use case depending on what your users use.
While not discussed here, Azure AD Certificate-based authentication is also a strong and phishing-resistant passwordless method. Since it's now natively integrated into Azure AD, it makes a lot of sense for companies that used to rely on ADFS to achieve the same passwordless result.
Enable FIDO2 security keys
To enable users to use FIDO2 keys, first sign in to the Authentication methods page, then click on FIDO2 Security Key:
From the menu, select “Enable“, then either “All users” if you want the entire organization to be able to use FIDO2 keys or scope the deployment to a specific group. You may also scope the feature to “All users” but exclude a specific group of people.
Under “Configure“:
You’ll generally want to leave “Allow self-service set up” set to “Yes“. This allows people to set up their keys.
“Enforce attestation” to “Yes“, as it allows to verify the quality and certifications of the key.
Enforce key restrictions to “No“, as it allows you to set which FIDO keys are allowed by the org and what keys are not.
Save and end the setup.
Register a FIDO2 key
Before registering a FIDO2 key, the user will be prompted to setup MFA. If you want the user to directly use FIDO2 keys as an authentication method, you can create a Temporary Access Password for them. This will skip the MFA prompt and let the user configure directly the key. To create a TAP, follow this guide: Configure a Temporary Access Password | Entra
If you are using Temporary Access Passwords, the user will be prompted to use it to authenticate.
If the user had MFA configured, the user will be able to configure the FIDO2 keys directly
If the user is authenticating with password-only, the user will be prompted to configure MFA as an additional step.
Click Security Info. In this case the user had MFA configured, so we can go straight to FIDO2 keys.
Click on “Add method“, then “Security key”.
Click on either “USB device” or “NFC device”. In my case, using a YubiKey 5 NFC, I’ll select USB, since I have it attached to the device. Note that this is just for registration, any method can be used for signing in after registration.
Insert the key, then press “Next“.
You will be redirected to a browser prompt, asking you to create a passkey. Select “External security key or built-in sensor“
If prompted, accept the following pop-up.
Create a PIN for your Security Key, then perform the gesture, such as touching the sensor.
Now give the key a name, so that you may recognize it. I generally suggest the ” Vendor + model” naming convention.
Click Done.
Now if you log-off, you’ll be able to test out the new key.
Test the FIDO2 key
Once you are done with the setup, try signing in with the key. To do that:
Access office.com or any other portal, then select “Sign-in options“.
Select “Sign in with Windows Hello or a security key“. This might come up as just “Sign in with a security key“.
Attach your Security Key, then insert your PIN
Perform the gesture, such as touching the sensor.
If all went well, you’ll access the portal.
Configure security keys as a sign-in option in Windows
Before starting, please be aware that for sign-in in Windows, you’ll need the machine to be at least version 1903. There are no requirement on the join type, as FIDO2 keys can be used for both Azure AD Joined devices and Hybrid-AAD Joined devices.
Enable with Intune for all users
To use FIDO2 keys on Windows devices for all users in your tenant:
Either click on the following link, or access Intune, then click on “Enroll devices”, “Windows Hello for Business”. Windows devices enrollment | Intune
Click on Use security keys for sign-in, and set it to Enabled.
Targeted Intune deployment
To target specific device groups to enable the credential provider, use the following custom settings via Endpoint Manager:
Once you are done, configure the Assignments, then complete the wizard.
Enable with Group Policy
If you are not using Intune, you can enable the feature using GPOs. In this case only Hybrid Azure AD Joined devices are supported. Once you have created the GPO, the setting is located under Computer Configuration \ Administrative Templates \ System \ Logon. Next, click on Turn on security key sign-in, and set the policy to Enabled.
Force sync on a single device
If you want to test things out after applying the Intune policies, run the following command from your local PowerShell or force sync from Intune. Both will sync your settings with Intune.
Get-ScheduledTask | where {$_.TaskName -eq 'PushLaunch'} | Start-ScheduledTask
Windows Hello for Business deployment for AAD joined devices
An option for configuring WHfB is by using Intune device enrollment. The settings are placed under Windows enrollment settings and only allow scoping to all users.
If you want to do it more granularly, you can deploy a configuration policy that will do the trick. Note that the configuration policy has more options, such as “PIN recovery” and “Certificate for on-premise resources”.
For reference, you can also create GPOs and configure hybrid and on-premises services to deploy Windows Hello for Business, but that won’t be discussed in this article as it would be worth a dedicated article.
For all users
Either click on the following link, or access Intune, then click on “Enroll devices”, “Windows Hello for Business”. Windows devices enrollment | Intune
Click on Use security keys for sign-in, and set it to Enabled. Enabled will configure WHfB for all devices. Not configured will be used if you still want to use the feature but you don’t want Intune to manage it.
Review the image below and use it freely as a template for the settings. This is one of the better defaults I’ve come up with, but some settings will depend on your organization’s standards. One note, it’s generally a good idea to require TPM if your devices support it.
Select Create a profile, then click on Windows 10 and later, Templates, Identity protection.
Give the policy a name, then click Next
As before, this is one of the better defaults I’ve come up with, but some settings will depend on your organization’s standards.
Once you are done, configure the Assignments, then complete the wizard.
Force sync on a single device
If you want to test things out after applying the Intune policies, run the following command from your local PowerShell or force sync from Intune. Both will sync your settings with Intune.
Get-ScheduledTask | where {$_.TaskName -eq 'PushLaunch'} | Start-ScheduledTask
Conclusion
I hope this post was useful to you. If you spot any mistakes, feel free to reach out to me on Twitter or Linkedin.
Azvise 