Password-less FIDO2 Security Key Signin to Windows 10 HAADJ Devices

Hello everyone, my name is Liju and I am a Premier Field Engineer specializing in and Azure AD.

Fido2 support for single sign-on (SSO) was introduced first for cloud resources, and then expanded to include both cloud and on-premises resources. For both cases, you can use either Azure AD joined or Hybrid Azure AD joined Windows 10 devices.

Earlier this year, I was involved in a proof-of concept for the more likely scenario, using FIDO2 security keys to log on to Windows 10 devices that were Hybrid Azure AD joined for SSO to both cloud and on-premises resources. Here are my notes from the field.


FIDO2 Security Keys

For my testing and PoC, I used the Security Key from Yubico that supports FIDO2. This table lists other providers of similar FIDO2 keys.

The FIDO2 specification comes from the Fast IDentity Online (FIDO) alliance and includes the W3C's Web (WebAuthn) specification and FIDO Client to Authenticator Protocol (CTAP).

While WebAuthN APIs are used by web applications to access FIDO2 services, CTAP is used by a hardware platform to access hardware authenticators.

FIDO2 security keys provide strong password-less with an optional PIN that serves as an additional factor. Within Azure , successful using security keys satisfy two-factor security verification and allow for password resets.

As an alternative to keys that need to be inserted into USB ports, you can also purchase security keys that use Bluetooth Low Energy or NFC.

Azure AD Authentication using FIDO2 Security Keys

  • During registration of the security key, your Windows 10 device creates a new key pair using public key cryptography.
  • The public key is registered with Azure AD for your user account while the private key is stored on the security key. This key pair is unique for the security key and user.
  • During authentication, Azure AD sends a challenge.
  • The user supplies a gesture (PIN, touch, etc.) that unlocks the private key on the security key. Each security key may store multiple private keys, but only one PIN.
  • This private key is used to sign the challenge and the resulting “signed assertion” is sent back to Azure AD.
  • Azure AD verifies the signature of the assertion using the user's stored public key and if valid, the user is deemed authenticated.

Extending AD DS for FIDO2 Security Keys

As a pre-requisite to being able to authenticate using FIDO2 security keys and gaining single-sign on to on-premises resources, you will need to extend the on-premises Kerberos realm to Azure active directory. This is done by running the Set-AzureADKerberosServer cmdlet described later in the post.

This creates a read-only domain controller object named AzureADKerberos and an associated Kerberos ticket-granting ticket user account, krbtgt_AzureAD.



A key derived from the password of this TGT account is securely published to Azure AD. It is a good practice to reset the password of this and all krbtgt accounts on a regular schedule. To do this with the krbtgt_AzureAD account, use the Set-AzureADKerberosServer cmdlet with the -RotateServerKey switch.

As with the default configuration of any RODC, built-in privileged groups are not allowed to have their passwords cached on this RODC object.


What this means is that this authentication model will not apply to users who are members of the following groups:

  • CN=Account Operators,CN=Builtin,
  • CN=Server Operators,CN=Builtin,
  • CN=Domain Admins,CN=Users,
  • CN=Cert Publishers,CN=Users,
  • CN=Enterprise Admins,CN=Users,
  • CN=Schema Admins,CN=Users,
  • CN=Domain Controllers,CN=Users,
  • CN=Backup Operators,CN=Builtin,
  • CN=Administrators,CN=Builtin,

AD DS Authentication using FIDO2 Security Keys

  • Device logons using FIDO2 security keys authenticate against Azure active directory.
  • Upon successful authentication, Azure AD provides a Kerberos TGT for the user's on-premises AD domain, encrypted with the key derived from the password of the krbtgt_AzureAD account, along with an Azure AD Primary Refresh Token (PRT).
  • The TGT is then exchanged for a fully formed TGT from an on-premises active directory domain controller.
  • The client machine now has an Azure AD PRT and a full Active Directory TGT and can access both cloud and on-premises resources. For details on the authentication process, see SSO to on-premises resources using FIDO2 keys


The information here is up to date as of May 2020.

  • If you enroll multiple identities with a FIDO2 token, it will allow you to pick which identity to use when doing web authentication. If you take the same token and use it to logon a Windows 10 PC, it does not give you an option of which identity to use. It will automatically use the last registered FIDO2 identity on the token.
  • FIDO2 security keys are not supported for authentication to Windows Servers
  • Single sign-on using FIDO2 security keys is not supported for yet.


  • Windows 10 devices v2004 20H1 release or later that are hybrid Azure active directory joined.
  • Requires the latest version of Connect, and fully patched /2019 domain controllers.
  • Initial setup for each user requires internet connectivity and connection to a domain controller.
  • For uninterrupted access to domain resources, users logging on using security keys must have access to the internet at least once every 10 hours.
  • Compatible FIDO2 security keys. Microsoft requires some optional extensions of the FIDO2 Client-to-Authenticator Protocol (CTAP) specification to be implemented by the security key to ensure compatibility. For more information see FIDO2 security keys


Enable the combined registration experience

These steps allow for users to register one or more authentication methods (telephone, security key, authenticator app, etc.) and the methods for both Multi-Factor Authentication and self-service password reset (SSPR). Without this step, users will need to register for both separately, which may be confusing.

    1. Sign into the Azure portal as a user administrator or global administrator.
    2. Go to Azure Active Directory > User settings > Manage user feature preview settings.
    3. Under Users can use preview features for registering and managing security info, choose to enable for a Selected group of users or for All users.

Users can access manage mode by going to From there, users can add methods, delete, or change existing methods.

Reference: Combined security information registration for Azure Active Directory overview

Enable FIDO2 security key method

By default, FIDO2 security keys as an authentication method is not available to users of your Azure AD tenant. When enabling the option, you can choose to enable for all users or scope it to one or more groups. In the example shown, I scoped it to members of the FIDO2-Pilot-Users group

  1. Sign in to the Azure portal.
  2. Browse to Azure Active Directory > Security > Authentication methods > Authentication method policy (Preview).LijuV_1-1591132795684.png
  3. Under the method FIDO2 Security Key, choose the following options:
    1. Enable – Yes or No
    2. Target – All users or Select users
  4. Save the configuration.

Reference: Enable FIDO2 security key method

User registration of FIDO2 security keys

A user will first need to register a security key and add it as an authentication method in their security information page in Azure.

  1. Browse to
  2. Sign in if not already.
    1. If the user already has at least one Azure Multi-Factor Authentication method registered, they can immediately register a FIDO2 security key.
    2. If they don't have at least one Azure Multi-Factor Authentication method registered, they must add one. The next few screenshots show a user attempting to add a security key but being required to add a phone authentication method first.

    3. The following screenshots show adding a phone as an authentication factor for simplicity of the demo.
  1. Add a FIDO2 Security key by clicking Add method and choosing Security key.

  2. Choose USB device or NFC device.
  3. Have your key ready and choose Next.
  4. A box will appear and ask the user to create/enter a PIN for your security key, then perform the required gesture for the key, either biometric or touch.
  5. The user will be returned to the combined registration experience and asked to provide a meaningful name for the key so the user can identify which one if they have multiple. Click Next.
  6. Click Done to complete the process.

Reference: Enable FIDO2 security key method

Enabling FIDO2 security keys on Windows 10 devices.

Before being able to log on to Windows 10 devices using FIDO2 security keys, you need to enable this functionality. There are several ways to do this. Here we will see two; you only need any one of the options.

Intune Identity Protection Device Configuration Profile

  1. Sign in to the Azure portal.
  2. Browse to Microsoft Intune > Device configuration > Profiles
  3. Create a Profile that enables security keys for sign-in
  • Platform: Windows 10 and later
  • Profile: Identity Protection
  • Name: Security Keys for Sign-in (Identity Protection) (example)
  • Description: Configure security keys as a sign-in option for Windows 10 devices. (example)
  • Use security keys for sign-in: Enable
  • Assign to: Selected groups (example)





Upon successful deployment, this sets the registry value on the device: HKLMSOFTWAREMicrosoftPoliciesPassportForWorkSecurityKey – UseSecurityKeyForSignIn (DWORD): 1

Group Policy

  1. Create a Object and configure the setting Computer Configuration Administrative Templates System Logon Turn on security key sign-in: Enabled

This sets the registry value: HKLMSoftwarePoliciesMicrosoftFIDO – EnableFIDODeviceLogon (DWORD): 1


  1. Link the to the OU that contain the Windows 10 device.

Reference: Enable security keys for Windows sign-in

Extending on-premises Kerberos domain to Azure AD.

  1. On the machine running the latest version of Azure AD Connect, open an elevated PowerShell console and run the following command to import the AzureAdKerberos module:
Import-Module "C:Program FilesMicrosoft Azure Active Directory ConnectAzureADKerberosAzureAdKerberos.psd1"
  1. This module provides 3 PowerShell cmdlets:

Get-Command *AzureADKerberosServerCommandType     Name                                               Version    Source
-----------     ----                                               -------    ------
Cmdlet          Get-AzureADKerberosServer                    AzureAdKerberos
Cmdlet          Remove-AzureADKerberosServer                 AzureAdKerberos
Cmdlet          Set-AzureADKerberosServer                    AzureAdKerberos
  1. Run the Get-AzureADKerberosServer cmdlet to determine if your domain has been extended to Azure AD. In the sample commands shown hereon, is the DNS name of the on-premises active directory domain.
Get-AzureADKerberosServer -DomainCredential $domainCred -CloudCredential $cloudCred -Domain HyperCruise.caId                 :
UserAccount        :
ComputerAccount    :
DisplayName        :
DomainDnsName      :
KeyVersion         :
KeyUpdatedOn       :
KeyUpdatedFrom     :
CloudDisplayName   :
CloudDomainDnsName :
CloudId            :
CloudKeyVersion    :
CloudKeyUpdatedOn  :
  1. Extend your on-premises Kerberos domain to Azure AD using the Set-AzureADKerberosServer cmdlet. In the example below,
    • $domainCred – credentials for member of Domain Admins
    • $cloudCred – credentials for user assigned the global administrator role
Set-AzureADKerberosServer -DomainCredential $domainCred -CloudCredential $cloudCred -Domain
  1. Running the Get-AzureADKerberosServer cmdlet again shows the information about the new computer object created in the on-premises active directory domain and the associated KRBTGT account:
PS C:Temp> Get-AzureADKerberosServer -DomainCredential $domainCred -CloudCredential $cloudCred -Domain

Id : 22973
UserAccount : CN=krbtgt_AzureAD,CN=Users,DC=HyperCruise,DC=ca
ComputerAccount : CN=AzureADKerberos,OU=Domain Controllers,DC=HyperCruise,DC=ca
DisplayName : krbtgt_22973
DomainDnsName :
KeyVersion : 147955
KeyUpdatedOn : 2/18/2020 7:53:12 PM
KeyUpdatedFrom :
CloudDisplayName : krbtgt_22973
CloudDomainDnsName :
CloudId : 22973
CloudKeyVersion : 147955
CloudKeyUpdatedOn : 2/18/2020 7:53:12 PM

Reference: Enable passwordless security key sign-in to on-premises resources with Azure Active Directory

User Experience


The two sections below show using screenshots for password-less sign-in using FIDO2 security keys to a Windows 10 desktop and to a web application through a browser.

Windows 10 lock screen



Authentication grants access to on-premises active directory resources.


Web applications and services

  1. When logging on to web applications like the Azure portal or the Security Info page, click Sign-in options.
  2. Choose the option to sign in with a security key.
  3. Enter the PIN to unlock the key and provide the additional gesture required.


As mentioned earlier, if you enroll multiple identities with the same FIDO2 token:

  • Its one gesture (PIN, biometric, etc.) per security key, to unlock all private keys.
  • When authenticating against a web application, after completing the gesture, you can choose between the identities.


However, this does not work for it to logon a Windows 10 PC; it does not give you an option of which identity to use. It will automatically use the last registered FIDO2 identity on the token.

Security Key Management

Creating a new security key PIN

  1. Open the Windows Settings app, select Accounts, select Sign-in options, select Security Key, and then select Manage.
  2. Insert your security key into the USB port or tap your NFC reader to verify your identity.
  3. Select Change from the Security Key PIN area, enter the existing PIN, type and confirm your new security key PIN, and then select OK.
  4. The security key is updated with the new security key PIN

Resetting security key

  1. Open the Windows Settings app, select Accounts, select Sign-in options, select Security Key, and then select Manage.
  2. Insert your security key into the USB port or tap your NFC reader to verify your identity.
  3. Select Reset from the Reset Security Key area.
  4. Follow the on-screen instructions, based on your specific security key manufacturer.

Resetting your security key deletes everything from the key, resetting it to factory defaults; all data and credentials will be cleared.

Deleting Security key from Security Info

  1. Browse to
  2. Select the Delete link from the security key to remove.
  3. Select Ok from the Delete security key box.


Events will be logged under the Microsoft-Windows-WebAuthN/Operational log, and are quite detailed. The main events are given in the table below:

Id Task Category Description Level
1003 WebAuthN Ctap GetAssertion WebAuthN Ctap GetAssertion started. Information
1004 WebAuthN Ctap GetAssertion WebAuthN Ctap GetAssertion completed. Success
1005 WebAuthN Ctap GetAssertion WebAuthN Ctap GetAssertion completed. Error
2100 Ctap Command Ctap GetAssertion started. Information
Ctap GetInfo started. Information
Ctap MakeCredential started. Information
Ctap NotifyStart started. Information
Ctap NotifyStop started. Information
2102 Ctap Command Ctap GetAssertion completed. Success
Ctap GetInfo completed. Success
Ctap MakeCredential completed. Success
Ctap NotifyStart completed. Success
Ctap NotifyStop completed. Success
2103 Ctap Command Ctap GetAssertion completed. Error
2104 Ctap Device Info Ctap device info. Information
2220 Ctap Usb Add Ctap Usb add device. Information
2222 Ctap Usb Changes Ctap Usb device changes. Information

CTAP commands and description

  • authenticatorMakeCredential – generation of a new credential in the security key.
  • authenticatorGetAssertion – request cryptographic proof of user authentication
  • authenticatorGetNextAssertion – called when more than one credential is stored on the key. List is displayed allowing for user to select the credential to use.
  • authenticatorGetInfo – request for information about the security key.
  • authenticatorReset – reset a security key back to a factory default state, invalidating all generated credentials.

This has been a long post, but hopefully the information in it can shed some light on how FIDO2 security keys work for SSO to on-premises and cloud resources, and make it easier to deploy this to your users.


This article was originally published by Microsoft's ITOps Talk Blog. You can find the original article here.