Microsoft keeps its Password-less promise and ships native FIDO2 support to Azure AD & Windows 10
Microsoft continues to deliver it’s password-less promise and introduces native FIDO2-based authentication to Windows 10 & Azure AD.
“There is no doubt that over time, people are going to rely less and less on passwords. People use the same password on different systems, they write them down and they just don’t meet the challenge for anything you really want to secure.”
Bill Gates, RSA 2004
The why, because passwords are not enough!
Going back to Ignite 2018, password-less sign-in was announced as one of the highlights alongside Confidential Computing and Microsoft Threat Protection. Alex Simons and Manini Roy showed us the first baby steps of Microsoft password-less promise. In their session ”Getting to a world without passwords ” they showed us how frictionless authentication methods like FIDO2 and WebAuthN are on the rise and how fits into the Microsoft ecosystem. It was actually a sneak peak how password-less promise would work for enterprises using your corporate credentials based on Azure AD.
With Microsoft Phone Sign-in, Windows Hello and Security Keys, Microsoft provides new and enhanced solutions that can help you provide secure, password-less options for your users to help protect your company from password spray, phishing, shoulder serving, and other attacks. Password-less authentication methods are more convenient because it eliminates the password from the authentication completely and replaces it with something you have (either your phone or security key) and something you are (like a biometric that’s tied to the something you are) or something you know (like a PIN that’s tied to something you have).
Microsoft recognizes that while Multi-Factor Authentication in addition to password is a great way to secure your resources, many users get frustrated with an additional layer on top of having to remember their passwords. The process of enabling password-less sign-in options consists of the following steps (in order of configuration):
- Enable security keys for Windows sign-in (Microsoft Intune)
- Enable password-less authentication methods (Azure AD)
- User registration & management of FIDO2 security keys (Azure AD)
When we are talking about password-less sign-in options we can identify the following options Azure AD provide us:
- Microsoft Authentication app
- FIDO2 Security Keys
Microsoft Authenticator App
Empower your employee’s phone to become a password-less authentication method. You may already be using the Microsoft Authenticator App as a convenient multi-factor authentication option in addition to a password. But now, it’s available as a password-less option. It turns any iOS or Android phone into a strong, password-less credential by allowing users to sign in to any platform or browser by getting a notification to their phone, matching a number displayed on the screen to the one on their phone and then using their biometric (touch or face) or PIN to confirm.
Note: Previously, for this you had to configure this with Azure AD policy for your entire tenant using PowerShell. With the introduction of Authentication Methods you’re able to select a group of users or choose all to deploy it to everyone in your tenant.
FIDO2 Security Keys
FIDO2 security keys are an unphishable standards-based passwordless authentication method that can come in any form factor. Fast Identity Online (FIDO) is an open standard for passwordless authentication. It allows users and organizations to leverage the standard to sign in to their resources without a username or password using an external security key or a platform key built into a device.
While there are many keys that are FIDO2 certified by the FIDO Alliance, Microsoft requires some optional extensions of the FIDO2 CTAP specification to be implemented by the vendor to ensure maximum security and the best experience.
A security key MUST implement the following features and extensions from the FIDO2 CTAP protocol to be Microsoft-compatible:
|#||Feature / Extension |
|Why is this required?|
|1||Resident key||This feature enables the security key to be portable, where your credential is stored on the security key.|
|2||Client pin||This feature enables you to protect your credentials with a second factor and applies to security keys that do not have a user interface.|
|3||hmac-secret||This extension ensures you can sign in to your device when it’s off-line or in airplane mode.|
accounts per RP
|This feature ensures you can use the same security key across multiple services like Microsoft Account and Azure Active Directory.|
For public preview, users can use external security keys to sign in to their Azure Active Directory Joined Windows 10 machines (running version 1809 or higher) and get single-sign on to their cloud resources.
- Azure Multi-Factor Authentication
- Combined registration preview
- FIDO2 security key preview requires compatible FIDO2 security keys
- WebAuthN requires Microsoft Edge on Windows 10 1809 or higher
- FIDO2 based Windows sign-in requires Azure AD joined Windows 10 version 1809 or higher
Note: currently FIDO2-based support isn’t available (yet) for Hybrid Azure AD Joined devices.
Devices that you will be piloting with must be running Windows 10 version 1809 or higher. The best experience is on Windows 10 version 1903 or higher.
|Windows 10 1809||Windows 10 1903|
|FIDO2||Only available in Shared PC mode||Available as primary authentication Method enabling via Microsoft Intune|
Enable security keys for Windows sign-in (Microsoft Intune)
Enough talk for now and let’s have a look at the configuration and operation of FIDO2-based sign-in works. Before we can log in with FIDO2 Security Keys we have to add FIDO2 as logon credential provider. To target specific device groups to enable the credential provider, use one of the following configuration options via Microsoft Intune.
Intune Device Restriction
Intune Custom OMA-URI
Enable password-less authentication methods (Azure AD)
Now we’ve enabled (Windows Hello) Security Keys as logon (credential) provider on Windows 10 (1903 or higher) the next step is to enable FIDO2 as Authentication Methods in Azure AD. By enabling this, users can use Microsoft Authenticator app and/or Security Keys as a login method assigned to there Azure AD account.
Self-Service Provisioning by end-users
Furthermore you can indicate in the Authentication Method policy whether or not users are allowed to issue their own Security Keys so that it’s no longer needs to be issued by IT.
Note: target the FIDO2 Authentication Method to the same Azure AD Security Group(s) as you’ve targeted the Microsoft Intune policy (configuration) in the previous step. Now we have completed the base configuration in place we can move on to the end-user section.
Key Restriction Policy
By configuring Key Restriction policies you are able to control which type of Security Keys (e.g. vendor, model, type, etc.) which can be used in your organization. This is done by using the AAGUID (Authenticator Attestation Globally Unique ID) which is a unique model number of your Security Key(s).
Note: The FIDO2 specification states that an AAGUID must be provided during attestation. An AAGUID is a 128-bit identifier indicating the type of the authenticator. Authenticators with the same capabilities and firmware, such as the YubiKey 5 series devices without NFC, can share the same AAGUID. The AAGUID information can be retrieved from your Security Key vendor website.
|YubiKey 5 NFC||fa2b99dc-9e39-4257-8f92-4a30d23c4118|
|YubiKey 5C Nano||cb69481e-8ff7-4039-93ec-0a2729a154a8|
|eWBM Goldengate G310||95442b2e-f15e-4def-b270-efb106facb4e|
User registration & management of FIDO2 security keys
Now we have enabled Security Keys for Windows sign-in and configured password-less authentication methods in Azure AD we are ready for the final step and register (provisioning) a Security Key from a end-user perspective.
The final steps remain us from password-less sign-in using Security Keys is adding an additional method to authenticate in Azure AD. Browsing to the updated Azure AD User Security Profile you just select Add method and choose Security Key (this option became available as we previously configured Authentication Method policy).
Note: provisioning of security Keys is currently only supported by Microsoft Edge, Mozilla Firefox version 66 and above and will soon be supported on Chromium-based browsers, including Microsoft Edge on Chromium and other browsers supporting FIDO authentication.
Returning back to your Security Info tab, you’ll notice the Security Key has been added as an additional authentication method.
The convenient user experience
A great start, but you just started your password-less journey...
Introducing password-less in an Cloud world is almost natural and straightforward. Applications you’re using talking modern authentication, SaaS applications taking benefit of Single sign-on. But I believe still not living in an ideal world, realistically most organizations are on the brink of taking their first steps towards the cloud or cautious on the road to capitalize the benefits cloud technology offers.
Implementing password-less is no exception to the rule here either, the more for organizations which, are in between. The biggest challenge to overcome and being successful is to modernize your application landscape, not only from an identity perspective but also from lifecycle- and management. Often there is no solid business-case or incentive to overcome this challenge in the first place. Such renewal processes are notorious for their costs, lengthy and impact it can have on your organization. but don’t let that stop you from starting. the longer you wait, the greater the barrier to overcome.
Microsoft drafted a 4-step strategy going password-less, which can be found here, to kickstart your password-less journey. Yes, it’s a journey as many others but the great thing about this one is you can implement your password-less strategy in your own pace in a phased approach in order to reap the benefits down the line.
How about enterprise who wish not to be part of Azure? is it still possible to do so?
Hi Preetam, currently only on-premise Windows Hello for Business provides passwordless experience. All other passwordless options (Microsoft Authenticator, Security Keys, Windows Hello for Business (cloud/hybrid) has somehow more or less cloud integration .
Thanks Ronny for your reply and clarification. I totally agree. MS has less focus on-premises solution. I tried http://vzare.com/windows-hello-business-beginners-guide/ but could not complete the series as it did not work at all. So many problems.
With all do respect, please consider a hybrid scenario with as starting point. Consider a strategy which fits your organization needs in your own pace, but you won’t achieve this with a touch of cloud…whether you like it or not. If the organization is reluctant then they have to accept the drawbacks and limitations.
If you’re not willing to make a compromise, you won’t be able to leverage the benefits Cloud has to offer including a more convenient and secure login methods.
Thanks for the article. However, after going through all the steps and it looking just like in your pics, the Windows logon doesn’t give me the key option; only smartcard, which when chosen states there are no valid certs on the smart card.
(Using the Yubikey 5C on AAD-joined devices)
One comment though… you say the FIDO2 auth setting in AAD should be assigned to the same group as is the Intune setting, but the Intune setting you say should be device group-based. In any case, it shouldn’t matter as long as your user has both applied.
Hi Fergus, please make sure you successfully deployed “Use security keys for sign-in” setting as part of your Windows Hello for Business (tenant-wide) configuration or via Identity Protection policy. For completeness, I assuming you’re using a Windows 10 1903 build which is Azure AD Joined.
Yes, I already have the WHfB config set up, to which I added the “use security keys…” setting.
Using 1903 AAD-joined.
In your previous comment you referred to “device-based” targeting, however I rather prefer (common practice) user-based assignment/deployment. Please give it a try and make sure the policy “hits” your device successfully. Please make sure the FIDO2 credential provider (see below) is available on your device.
I can confirm that registry entry is present, with a single REG_SZ entry of “FIDO Credential Provider”.
My comment about the device group was in relation to your statement “To target specific device groups to enable the credential provider…” which suggests you’re assigning the Intune policy by device. In any case, I have assigned that and the AAD auth setting to the same (user) group.
It seems like Windows sees the key as a smartcard. Does Device Manager show yours as “Smart Cards \ Identity Device (NIST SP 800-73 [PIV])” ?
I wonder if somehow our AppLocker policy is getting in the way.
Wouldn’t be the first time. :-)
Time to investigate further…
Further to our conv above, I found that the WHfB policy doesn’t work. The OMA-URI, however, does the job nicely and I can now log on using the Yubikey 5C.
A similar article (https://alven.tech/passwordless-with-windows-10-and-yubikey/) includes the OMA-URI as a requirement, but steps 1 was not necessary for me.
Strange that we get different behaviour when apparently all the other variables are the same!
Thanks for circling back, interesting 🤔 Both approaches should work, most preferably via Identity Protection policy.