How-to: Password-less FIDO2 Security Key Sign-in to Windows 10 HAADJ Devices

Published Jun 03 2020 06:42 AM 46.4K Views

Hello everyone, my name is Liju and I am a Premier Field Engineer specializing in Active Directory 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.


1    Overview


1.1  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 Authentication (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 authentication with an optional PIN that serves as an additional factor. Within Azure active directory, successful authentication 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.


1.2  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.


1.3  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,<Domain_DN>
  • CN=Server Operators,CN=Builtin,<Domain_DN>
  • CN=Domain Admins,CN=Users,<Domain_DN>
  • CN=Cert Publishers,CN=Users,<Domain_DN>
  • CN=Enterprise Admins,CN=Users,<Domain_DN>
  • CN=Schema Admins,CN=Users,<Domain_DN>
  • CN=Domain Controllers,CN=Users,<Domain_DN>
  • CN=Backup Operators,CN=Builtin,<Domain_DN>
  • CN=Administrators,CN=Builtin,<Domain_DN>


1.4  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


2    Limitations

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 RDP yet.


3    Requirements

  • Windows 10 devices v2004 20H1 release or later that are hybrid Azure active directory joined.


  • Requires the latest version of AAD Connect, and fully patched Server 2016/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


4    Configuration


4.1  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.
      • LijuV_0-1591192249856.png
    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.
      • LijuV_0-1591132698272.png


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




4.2  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.
    • LijuV_0-1591193206381.png




4.3  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.
      • LijuV_1-1591133105771.png
      • LijuV_2-1591133119729.png
      • LijuV_3-1591133130624.png
      • LijuV_5-1591133153037.png
    3. The following screenshots show adding a phone as an authentication factor for simplicity of the demo.
      • LijuV_6-1591133184623.png
      • LijuV_7-1591133237779.png
      • LijuV_8-1591133246278.png
      • LijuV_9-1591133254407.png
      • LijuV_10-1591133262354.png
      • LijuV_11-1591133270991.png
  1. Add a FIDO2 Security key by clicking Add method and choosing Security key.
    • LijuV_12-1591135016283.png
    • LijuV_14-1591133394549.png
  2. Choose USB device or NFC device.
    • LijuV_0-1591133620217.png
  3. Have your key ready and choose Next.
    • LijuV_2-1591133796078.png
  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.
    • LijuV_3-1591133807764.png
    • LijuV_5-1591133863892.png
    • LijuV_6-1591133877435.png
  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.
    • LijuV_7-1591133935268.png
  6. Click Done to complete the process.
    • LijuV_8-1591133956879.png




4.4  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.


4.4.1  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: HKLM\SOFTWARE\Microsoft\Policies\PassportForWork\SecurityKey - UseSecurityKeyForSignIn (DWORD): 1


4.4.2  Group Policy

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

This sets the registry value: HKLM\Software\Policies\Microsoft\FIDO – EnableFIDODeviceLogon (DWORD): 1


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




4.5  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 Files\Microsoft Azure Active Directory Connect\AzureADKerberos\AzureAdKerberos.psd1"



  1. This module provides 3 PowerShell cmdlets:


Get-Command *AzureADKerberosServer
CommandType     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
Id                 :
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





5    User Experience


5.1  Authentication

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.


5.1.1  Windows 10 lock screen




Authentication grants access to on-premises active directory resources.



5.1.2  Web applications and services

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


    • LijuV_13-1591135031202.png
    • LijuV_14-1591135044547.png
    • LijuV_15-1591135054559.png


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.


5.2  Security Key Management


5.2.1  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


5.2.2  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.


5.2.3  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.


6    Troubleshooting

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



Task Category




WebAuthN Ctap GetAssertion

WebAuthN Ctap GetAssertion started.



WebAuthN Ctap GetAssertion

WebAuthN Ctap GetAssertion completed.



WebAuthN Ctap GetAssertion

WebAuthN Ctap GetAssertion completed.




Ctap Command

Ctap GetAssertion started.



Ctap GetInfo started.



Ctap MakeCredential started.



Ctap NotifyStart started.



Ctap NotifyStop started.



Ctap Command

Ctap GetAssertion completed.



Ctap GetInfo completed.



Ctap MakeCredential completed.



Ctap NotifyStart completed.



Ctap NotifyStop completed.



Ctap Command

Ctap GetAssertion completed.




Ctap Device Info

Ctap device info.



Ctap Usb Add

Ctap Usb add device.



Ctap Usb Changes

Ctap Usb device changes.



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.

Senior Member

Great article thanks, looks like its getting closer to being ready for prime time. Are there any security risks we should know about with extending on-premises Kerberos domain to Azure AD? That part seemed a little concerning.

Senior Member

Such a helpful write-up!!  Exactly what I needed.  


@freds123 : In transit, the krbtgt secret of the RODC object is first encrypted with Azure AD's public transport key, and then sent with TLS security. At rest, the secret is encrypted with a symmetric key that never leaves the key vault attached to Azure AD's token service.

Hopefully, this helps address any questions you have about the security of extending the kerberos domain to Azure.

Regular Contributor

I have a security key set up successfully as an authentication type in AzureAD, and can sign into Azure AD joined devices without issue.  I've followed these steps, but I can't seem to get it to work for logging in to Hybrid AADJ computers.  When I try to log on with a security key, I get an error:
"Your credentials couldn't be verified (code: 0xc000006d,0x0)"


I've looked in the webauthn logs as suggested in this article, and I see the Ctap GetAssertion steps, with the error "0x52E The username or password is incorrect."  Do you have any suggestions as to what might cause this, or where I should look next for further troubleshooting?  


@Steve Whitcher is the account you are attempting to log on to a member of a protected group in AD?

Regular Contributor

That is an excellent question!  I checked the account against the list of groups in this post and thought it was clear, but it turns out there was a nested group membership that I missed.  After removing that membership, I'm now able to sign into a hybrid AADJ computer with a fido2 key.  Thanks!


Senior Member

When trying to authenticate with a Hybrid joined win10 (2004) machine, we see that the Security Key tile is out of focus, so we need to click a different tile and then click again on the Security Key tile. In some cases the security key needs to be unplugged and then plugged back in to bring up the PIN dialogue. Looking at event viewer, we see events 2202, 2103 and 1005 with error "0x52E. The user name or password is incorrect". Will appreciate any insights as to what is happening. We are able to successfully sign in with the security key, it's just that the user experience is not as smooth as it could be, and we wonder if those errors are indicative of a problem. 

Occasional Visitor

This is a great resource! Thanks a lot for this.


Like a few people above, I too had the error "Your credentials couldn't be verified (code: 0xc000006d,0x0)"

Finally using this guide, we figured I was still part of a nested protected group which caused the issue. All sorted and can login now without issue


Looking forward to the RDP authentication in the future 

Senior Member



Thank you for the share, very easy to follow !


Everything is in place, i can login  on my laptop and access web app with my yubikey but only when i'm connected to my company network.

If i am at home without VPN i can't open session (server unavailable). 


My computer is azureadjoin et domainjoined



Is there a way to get this running outside my company network ?



Senior Member

Like @MiguelRodriguezS i also have Event id 2202, 2103 and 1005 in WebAuthN event viewer.



New Contributor



Have exactly same problem as @Bpatin .


Device is HAADJ, I can login with my Security Key (Yubikey 5) when connected on my company lan.

But when I'm Out-Of-Office, i can't login with Security Key until i open the VPN.


When I look at AAD portal, I can see a successful sign-in with my Security Key.


Our device are co-managed, SCCM on-prem + Endpoint Manager, someone tolds me that it could be the cause.


By the way, if it doesn't work when Out-Of-Office, it's because at one moment, my computer try to reach an On-Prem server (AD, SCCM).


What shall I do for it to work also Out-O-Office?


@FredChaussee @Bpatin @MiguelRodriguezS 
We are investigating internally this issue and I will reply to this post as soon as we have an update. 

Senior Member



I'm so glad I found this.  We too are having issues with users not able to authenticate with FIDO2 when not connected via VPN or on-prem.  Funny thing is our test group that started a few months ago still work, including mine.  Anyone that has registered as of late can only login when connected to VPN.


Windows 10 2004 with latest patches. Feitian BioPass FIDO2 Security Keys.


The one log entry I notice in the WebAuthN Operational logs that is different than mine is Event ID 2212.  Hope this helps.


Ctap Usb device thread completed.

TransactionId: {1dde373d-xxxx-xxxx-bba6-c43a3db04fb5}
DevicePath: \\?\hid#vid_096e&pid_085d&mi_00#7&363d572f&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}
AAGuid: {77010bd7-212a-4fc9-b236-d2ca5e9d4084}
U2fProtocol: false
State: 5
Status: 0x21
Error: 0x80090320. The credentials supplied were not complete, and could not be verified. The context could not be initialized.


Frequent Visitor



I've got same experience with windows authentication using FIDO2 keys as @G-At-Work . Test group added yubikeys in Feb, this works for Win10 login without issues, but keys added/ installed now requires vpn or to be on-prem for users to be able to login to win10. Even on the same PC, one key added few months sooner works fine, the one added recently returns error without direct/vpn company network connection "Sorry, try that again. There was an issue with the server"


We are investigating if this issue is related to the different Windows 10 builds (20H2 vs 20H1)

Senior Member

Thanks @LijuV 

Another thing worth clarifying is the topic of FIDO2 offline login. According to the specs, the hmac-secret is supposed to work for offline cases, provided the user has previously had a successful authentication using a security key on that particular Windows 10 device. This is not what we are finding out with hybrid joined devices. From reading the FIDO and CTAP2 specs, it looks like the hmac-secret is set during the AuthenticatorMakeCredential call, so it means that this is during registration. But still offline login (no wifi, no ethernet, airplane mode) doesn't work with FIDO2 security keys. Do let us know what you find, we're happy to contribute logs/even viewer information.

Senior Member



Any updates ?




@Bpatin not yet, unfortunately. This issue is being actively worked on internally and I will post a comment as soon as I have an update.

Established Member

Some information, should it be relevant to others:

  • I'm able to login using a YubiKey 5 NFC security key, when in the corporate network (office or VPN), internet only or when completely offline but had associated the key a while ago and subsequently installed updated to now be running Windows 10 v20H2.
  • New user that is running Windows 10 v20H2, also with a YubiKey 5 NFC, is unable to login when they do not have line of sight to AD servers.


It's also massively confusing getting users to understand that only the last Azure AD / Office 365 account associated with a Security Key to be the one that Windows attempts to use during login. This means that users that get assigned priviledged Azure AD accounts (eg adm-azure-xxx@blahblah) need to jump through the following hoops:

Windows login will then authenticate using the day-to-day account as it was the last account associated with the key...

Senior Member

Just wanted to point out this info that was brought to our attention by our customer in Nunavut, Canada:  it now states (updated 21/04/2021): Cached logon with FIDO2 keys fails on hybrid Azure AD joined devices on Windows 10, version 20H2. As a result, users will not be able to login when line of sight to the on-premises domain controller is unavailable. This is currently under investigation.

Senior Member

@LijuV Thank you for posting this detailed article! Any updates on the cached login issue?


I think this is out of preview at this stage, correct? We just stumbled across this post after fighting the same issue, which is somewhat of a relief. But it's quite disconcerting that if this was already employed in production, it would have broken auth at a fundamental level for at least a month. That is triggering a reevaluation of the whole project for us. 

New Contributor

Hi @LijuV 


I just install 21H1 from insider program, still have the issue.

Do you have any updates?


@RH / @FredChaussee 
Unfortunately, no updates as of today. I cannot say when the fix will be available because I don't know myself. I can guarantee you that the product team is actively working on this issue. I will update the post as soon as I hear of a workaround/fix.

New Contributor

Hi All,


@LijuV , @BPat12 @RH 

Great news.

My contact at Yubikey told me that Microsoft apply an update last week that resolve this issue.


I tested today, after a successful unlock of the PC while connected through VPN, i'm now able to connect on my PC even out of LAN.


For me, this issue is solved.


Thx all for your help.

Senior Member

tested...and approved !!


thanks @FredChaussee and to anybody who contribute to this update :smile:

Senior Member

Our customer confirmed that the issue is resolved too. Thanks @LijuV !

Senior Member

My colleague just confirmed it's working for us as well. Thank you, @LijuV@FredChaussee and others!

Occasional Visitor



Any chance it will work with 2012 R2 Domain Controller?


@szczepanl no - you will need at least 1-2 Windows Server 2016 or Server 2019 DCs per site.

Occasional Visitor

@FredChaussee what to do to solve the problem? We need a specific windows update for the client / server? My colleague inform me that the problem is there anymore outside the company network. Thanks for your help.

New Contributor

Hi @Jakov_Sapina ,

There's no update or fix to install.

It seems to be a o365 update.


Does it means that an account member of Domain Admin group is not able to use FIDO key ? If yes, is there another way ? Can we change the Password Replication Policy ?

Senior Member

From our findings: If you are getting the error message “Your credentials couldn’t be verified. (Code 0xC00006D, 0x0) when trying to log in this is because the account you are using is a member of the Domain admins , account operators, or enterprise admins groups. FIDO2 workstation login will not work with accounts that are members of those groups. I think the idea is to maintain a separation of concerns (regular user accounts vs. domain privileged accounts), but I'm sure Microsoft can explain in more detail what is their recommended approach. 


@zigune , yes you can change the PRP to include privileged groups. These groups are excluded by default to limit their exposure to online services besides Azure AD.

Occasional Visitor



the tutorial is great, but if got a problem when i want to log me in with the fido key on a Windows 10 HAADJ Device. I can`t login with the key i always get an error message that says "Please try again, there is an error on the server"...

In The Eventviewer I can`t see anything to this problem. Has anyone an idea what i can do now?

Senior Member

Hi @Dominik_Gruber 

recently i have seen that issue too. "the server" mentioned in that error message might be your onPrem domain controller. To get the eventlog entries regarding that issue use the affected client go to the eventlog "Microsoft \ Windows \ Security-Kerberos" and enable it in context menu. reproduce the error and then go back to the "security-kerberos" eventlog of that client and you got the reason.


Maybe the DC can't be connected (DNS, Port, wrong AD-Site associated,...) but you might see it there in detail.

Regular Visitor

@MiguelRodriguezS Hey! Did you ever get a resolution to your issue posted on ‎Mar 09 2021 03:00 PM? I am having the exact same issue. Luckily we caught it during testing before deploying to a larger audience, but now our project is delayed because of this issue. Would appreciate some info if you got this solved somehow!

Senior Member

@Chris954 @MiguelRodriguezS 

Did you try to leave and let the device join again with dsregcmd? Also check the registration status and maybe try afterwards to join the device azue ad only to know if device, cloud or onprem ist the problem.



Regular Visitor

Hey @Andreas_Rinner thanks for the reply, two of the computers we tested with were brand new adds to the Domain, I have checked dsregcmd on all of them and the settings all seem correct. Fido2 authentication works fine, the issue is we cannot click the "USB" icon right away without clicking something else first. In fact, when i come back from Hibernation or Locked State, it's supposed to come back to my last sign in method, instead there's nothing on the screen and just says "Sign In Options", Like this;


I'll check using a cloud only device, have to disjoin one of the test machines so I'll report back shortly.

Senior Member

Can confirm I have the same issue as @Chris954 - FIDO key login works fine, but from the lock screen you have to click "Sign in options", click the Password icon first, then click the USB icon to get it to ask for FIDO login.

Regular Visitor

Hey @Chris Sledge  , i opened a ticket with Microsoft and they identified this as a known issue. They are expecting a fix to be released sometime in Q1 of 2022. They said is available in DEV channel, but the build number they gave me is not available to download yet, Here is the email i got from Microsoft:


This fix is scheduled to be released in the third week of January as an optional update (Should be included in Feb’s Patch Tuesday as well), but it is possible that it could be delayed if something comes up between now and then.  If you would like to test the fix, it is available in the Dev Channel of Windows Insider with any build > 22466

Senior Member

@Chris Sledge @Chris954 

Can you check if using EnableFIDODeviceLogon OR UseSecurityKeyForSignIn makes a difference. As mentioned in 4.4 you need to enable only one. As these options enable the fido login option your problem might be related to how these are (not) applied. It's just a guess.

Regular Visitor

Hey @Andreas_Rinner , we just have HKLM\Software\Policies\Microsoft\FIDO – EnableFIDODeviceLogon (DWORD): 1 configured via GPO, i just confirmed it. The other Reg key in PassportForWork is not set.

Senior Member

In my case, UseSecurityKeyForSignin is enabled and EnableFIDODeviceLogon is not set.

Senior Member

FYI I did manage to get Dev Channel build 22483 installed and tested for FIDO login, and it actually made the situation worse. When clicking "Sign-in Options", the FIDO key icon is there, but the majority of the time clicking it did nothing.

Senior Member

I'm posting here because we have started to have issues with FIDO2 login lately.  We have had this deployed for months, and after the last windows 10 update to Version 20H2, we are having to connect to VPN before login, which allows line-of-site to our DC's, every couple days to continue login with FIDO2.  After that it works with just internet access for what seems like two days, maybe "X" logins and quits until a login with DC line-of-site is performed again.   In the past once logged in with a DC line-of-site ONCE, the FIDO2 login would continue working for months (possibly permanently without password change) with just internet access.


Also, I thought these where going to be able to work without internet access, which as of now, seems to be required to log in with FIDO2.


Has anyone else experienced this behavior change with FIDO2 login on windows 10 in the last month or so? 

Frequent Visitor

@G-At-Work I've been having the same problems lately, on multiple computers, version 21H2. Internet access has always been needed to log in.

Senior Member

We also have heard of a customer experiencing this issue right after the last (november 2) windows 10 update. They have opened a ticket with Microsoft.

Senior Member

@MiguelRodriguezS@G-At-Work@jmcz1: Yep, can confirm the issues. Currently most of our customers are working from home, so (without VPN) there is no access to the Domaincontrollers. When the login is performed the error @Dominik_Gruber mentioned appears. Event log reports no connection to DCs. After the user performs a login with line-of-site connection logins will go through without errors even without line-of-site connection afterwards for, what it seems like, 2 days until the error/issue reoccurres. Seems like that even with VPN connection set to active there is still a problem with the connection to the DC in our case. Is there any documentation about Ports and URLs needed or any update about if the feature will support successful logins without line-of-site connection @LijuV?

Senior Member

@LijuV We have the same problem with HAADJ devices and a FIDO security key when users are OOO. When leaving the office the first login at home with the securitykey works fine (and without a VPN connection to the office), but after locking the machine it isnt possible to login again.  The have to make a pre logon VPN connection with "old" username + password + certificate before the are able to logon a Windows with the security key. 

All the whitepapers we have found do not mention that is is necessary to have an active connection with an on-prem DC. 

This article explains the security key login:

Azure Active Directory passwordless sign-in | Microsoft Docs


  1. The user plugs the FIDO2 security key into their computer.
  2. Windows detects the FIDO2 security key.
  3. Windows sends an authentication request.
  4. Azure AD sends back a nonce.
  5. The user completes their gesture to unlock the private key stored in the FIDO2 security key's secure enclave.
  6. The FIDO2 security key signs the nonce with the private key.
  7. The primary refresh token (PRT) token request with signed nonce is sent to Azure AD.
  8. Azure AD verifies the signed nonce using the FIDO2 public key.
  9. Azure AD returns PRT to enable access to on-premises resources.

We have read the statement of an insight DC, but it isnt very clear. As far is i can understand it is needed for SSO to on premise resources:

Passwordless security key sign-in to on-premises resources - Azure Active Directory | Microsoft Docs


The remark about the Intune settings VS GPO: They are doing the same according this thread:

Both registry keys functionally do the same thing to turn on the cred prov, but If the Intune policy/regkey is set to enabled (UseSecurityKeyForSignin) it will take precedence even if the group policy regkey (EnableFIDODeviceLogon) is set to disabled.


We can use some help with troubleshooting the logon with the security key though....

Version history
Last update:
‎Jun 03 2020 07:12 AM
Updated by: