none
Windows Hello for Business only works for about an hour after enrollment RRS feed

  • Question

  • We recently configured ADFS 2019 to support Windows Hello for Business in our production domain (not hybrid - purely on-prem and using key trust not certificates). I put two laptops (one running v1903 and one running v1809) in an OU with the appropriate group policy to enable WHFB and was able to get my fingerprint enrolled. The enrollment process worked on both as expected. I was able to lock and unlock with my fingerprint and sign out and then back in. After about 45-60 minutes, I was no longer able to unlock or sign-in with my fingerprint or the PIN that I configured. I always get the error: "That option is temporarily unavailable" and I have to use my password to log in or unlock.

    On each failed fingerprint/PIN attempt in the security event log there is an audit failure event id 4625 with a status of 0xc000006d and sub status of 0xc00002f9 which appears to mean that the certificate has a missing or incorrect UPN.
    On the domain controller (all DCs are Windows 2016 with a certificate from our CA as per the WHFB documentation) at that same time, there is an audit failure for event 4768 where the result code is 0x4B which is KDC_ERR_CLIENT_NAME_MISMATCH per RFC 4120.

    In one test I got this error in the DC system event log: "The client certificate for the user OURDOMAIN\myusername is not valid, and resulted in a failed smartcard logon. Please contact the user for more information about the certificate they're attempting to use for smartcard logon. The chain status was : The operation completed successfully."
    Even though we selected to use key based Windows Hello, I do see a self signed certificate in my cert store. The name of the cert is formatted as S-1-rest-of-my-SID/GUID/login.windows.net/GUID/myusername@my.login.domain

    Can anyone explain what's going wrong? The error codes seem to indicate that the self-signed cert has the wrong UPN, but I clearly see the correct UPN in the subject name. Further I don't understand how it works a handful of times before failing seemingly forever. It does not seem to be machine specific either as two different versions of Windows on two different vendor's hardware exhibit the same behavior with the same error codes. I'm doubly confused because we tried this in a lab environment first without seeing this at all.

    Thursday, August 8, 2019 12:08 PM

All replies

  • Hi,

    Please check the link below about Windows 10 – Hello for Business – Return of the “That option is temporarily unavailable” message if it is helpful.

    http://www.itgeekrambling.co.uk/windows-10-hello-business-return-option-temporarily-unavailable-message/

    Please Note: Since the website is not hosted by Microsoft, the link may change without notice. Microsoft does not guarantee the accuracy of this information.

    Hope it will be helpful to you.


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Sunday, August 11, 2019 1:04 PM
    Moderator
  • I'm having almost the exact same issue.  I've found supporting information and in testing found that my single 2016 server works and the 2019 don't with that error:  KDC_ERR_CLIENT_NAME_MISMATCH.  Looked into the registry UseSubjectAltName  Kerberos registry change but still no success. 

    To be clear, I'm talking about my domain controllers, not ADFS.  I don't think ADFS is your problem.

    Found this feature request too, which what lead me to force it to the 2016 server.  

    https://feedback.azure.com/forums/169401-azure-active-directory/suggestions/37200370-whfb-is-not-working-with-server-2019-domaincontrol

    I did packet captures and you can clearly see the KDC_ERR_CLIENT_NAME_MISMATCH and then it is gone with 2016 server.

    Still working support on the issue.


    Friday, August 16, 2019 8:04 PM
  • Thank you! I think that you've identified the problem. I'd forgotten that we had introduced one 2019 DC for initial testing and on further inspection it does look like it is that DC that causes the error. If my laptop instead attempts authentication against one of the 2016 DCs then WHFB works just fine. Has MS support indicated if a fix is coming anytime soon?

    Monday, August 19, 2019 12:29 PM
  • Hi, 
    Was your issue solved?
    What is the current state of the issue?
    Best Regards,

    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Monday, September 9, 2019 3:49 PM
    Moderator
  • We're still having the issue. The root cause seems to be as James Evans described above - if the client tries to use a Windows 2019 domain controller (rather than Windows 2016) then WHfB authentication fails.
    Monday, September 9, 2019 3:56 PM
  • In our case, the msds-KeyCredentialLink property was being deleted from user objects shortly after enrolling for HfB.  This was a result of an incorrectly configured AAD sync.
    Friday, February 14, 2020 8:30 PM
  • Thank you! I think that you've identified the problem. I'd forgotten that we had introduced one 2019 DC for initial testing and on further inspection it does look like it is that DC that causes the error. If my laptop instead attempts authentication against one of the 2016 DCs then WHFB works just fine. Has MS support indicated if a fix is coming anytime soon?

    Check that your Server 2019 DC has the latest patches. There was a patch in 2019 that fixed issues.

    https://support.microsoft.com/en-us/help/4487044/windows-10-update-kb4487044
    Addresses an issue that causes the Windows Hello for Business Hybrid Key Trust deployment sign-in to fail if Windows 2019 Server domain controllers (DC) are used for authentication. The error is, "That option is temporarily unavailable. For now, please use a different method to sign in”. If Active Directory (AD) activity tracing is enabled, a Local Security Authority Subsystem Service (LSASS) exception may occur in the Windows 2019 DC when processing a user’s sign in.
    Friday, March 6, 2020 12:39 AM