Windows Hello Hybrid Azure AD joined with Key Trust, automatically creates a new key, why?

_KUL 286 Reputation points


Deployed the Windows Hello Hybrid Azure AD infrastructure joined with Key Trust.
Any user in the on-premises enterprise AD environment sets a PIN code, generates a key that is recorded in Azure AD, after 30 minutes, Azure AD Connect synchronizes the data and adds a new key to the attribute msDS-KeyCredentialLink user account. As it turned out, the msDS-KeyCredentialLink attribute is an array ... In the course of normal work, for unknown reasons, the user when trying to unlock the computer can not log in (about a month has passed), because the message on the screen "That option is temporarily unavailable". It turns out that the client program generated a new key (the user did not change the PIN code), passed it to Azure AD, and only after the next synchronization of Azure AD Connect, the user will be able to log in! And synchronization can be at least 30 minutes! I.e. the work is paralyzed for up to 30 minutes! And the msDS-KeyCredentialLink attribute in the local AD does not replace the key with a new one, but adds a new one to the array!

Question: why does automatic key generation occur (without the user's knowledge)? why store old keys in the msDS-KeyCredentialLink attribute? How can I avoid downtime if the minimum threshold for Azure AD Connect synchronization can only be set to 30 minutes? When using the Certificate Trust model, the key will not be stored in the msDS-KeyCredentialLink attribute, and this problem can be avoided?

Some details:
PIN-code was established relatively long ago (about a month ago), the computer is running Outlook and Teams, in the morning as usual the user entered PIN-code in the process (today 22.12.2020) it was noticed that Outlook asks to enter an additional password (usually this is not normally a problem with authentication), an attempt was made to lock the computer at 12:15 and discovered this feature described in the question.
but! After 3 hours, history repeats itself! There is no suspicious activity in the Windows security log! Where can I track activity? Is there a problem on the Azure AD Connect side?

More additional information
17:07 the entrance!
The msDS-KeyCredentialLink attribute of the user in local AD contains 4 keys - successful login!
The msDS-KeyCredentialLink attribute contains 3 keys. Access to network resources is not possible, login to the computer is not possible by pin-code.
17:24 appeared 4 the certificate! synchronization took place at 17: 22: 39!
Access to network resources works! I can enter by pin-code.
The msDS-KeyCredentialLink attribute again contains 3 keys ... no one except MSOL_4d60xxx has accessed the attribute! Replica not working correctly between the local domains?!

using-whfbtools-powershell-module-for-cleaning-up-orphaned-windows-hel Got a list of keys from Azure AD, they were all created in November ... it is strange that something started to fail ...

It was the second day of analysis ...
23.12.2020 the second user had a similar problem! look carefully at it!
The user in November created 2 keys (20-11-26 and 20-11-19), in AAD his profile has 2 keys. In AD, the msDS-KeyCredentialLink attribute has an array of 2 keys.
In a domain, for example, 10 domain controllers, the user "LOGONSERVER" is set to #1.
Today, the connector only made the following changes with the user:

When    What
23.12.2020 15:41    User 'ivanov.ivan' was modified by  'mydomain\MSOL_xxx' Modified Properties : msDS-KeyCredentialLink, Values : B:854:<Binary>
23.12.2020 15:11    User 'ivanov.ivan' was modified by  'mydomain\MSOL_xxx' Modified Properties : msDS-KeyCredentialLink, Values : B:854:<Binary>
23.12.2020 14:03    User 'ivanov.ivan' was modified by  'mydomain\MSOL_xxx' Modified Properties : msDS-KeyCredentialLink, Values : B:854:<Binary>
23.12.2020 13:33    User 'ivanov.ivan' was modified by  'mydomain\MSOL_xxx' Modified Properties : msDS-KeyCredentialLink, Values : B:854:<Binary>
23.12.2020 10:32    User 'ivanov.ivan' was modified by  'mydomain\MSOL_xxx' Modified Properties : msDS-KeyCredentialLink, Values : B:854:<Binary>,B:856:<Binary>
23.12.2020 10:02    User 'ivanov.ivan' was modified by  'mydomain\MSOL_xxx' Modified Properties : msExchSafeSendersHash

Next, an interesting story turns out!
General state:
AAD, AD: msDS-KeyCredentialLink 2 keys installed (AD on all controllers the same value)
Computer: turned on, logged in, locked
Azure AD Connect: syncing was successful 10 minutes ago

1_ The User successfully login using the Windows Hello for Business PIN-code
2_ Instantly, on domain controller #1 "LOGONSERVER" the msDS-KeyCredentialLink attribute becomes a value with 1 key (why???)!

    $arrDC = Get-ADDomainController -Filter * -Server mydomain
    $arrDC | ForEach-Object -parallel {$value = Get-ADUser -Server $_ -Identity ivanov.ivan -Properties msDS-KeyCredentialLink; write-output "$($value.'msDS-KeyCredentialLink'.count) $($_.HostName) $($value.'msDS-KeyCredentialLink')"}

3_ On local AD controllers, the replica starts and the value is set to 1 key (i.e. there is no correct key) on all controllers. The user begins to have errors with authentication in Outlook and with access to network drives.
4_ If we wait 20 minutes, Azure AD Connect brings msDS-KeyCredentialLink to the correct state (AD replicas update this), but if the user login again, the value will be corrupted again.

My thoughts: as if AD controller #1 "LOGONSERVER" after successful Kerberos authentication (client allows login) decides to delete this key from the user profile!

New Question: why is this happening (something is wrong with the key)? who does this (local controller)? how to predict it or how to get rid of it?

p.s. for the first user, the problem 23.12.2020 itself was eliminated, the attribute is no longer overwritten, the pin-code entry Windows Hello for Business works normally

Azure Active Directory
Azure Active Directory
An Azure enterprise identity service that provides single sign-on and multi-factor authentication.
16,558 questions
Active Directory Federation Services
Active Directory Federation Services
An Active Directory technology that provides single-sign-on functionality by securely sharing digital identity and entitlement rights across security and enterprise boundaries.
1,083 questions
{count} vote

Accepted answer
  1. Nagappan Veerappan 556 Reputation points Microsoft Employee

    I just found one of the known reported issue , I guess this may be related since I dont know unless you have support case and data to review.

    Please check the patch on your DCs and validate if that resolve your problem.

    @Brian Saville @_KUL
    Please validate and comment



    • You have Hybrid Windows Hello for Business key trust configured in your environment.
    • Users were able to enroll for WHfB, and they can sign in only once. But not for the second time.
    • Users can sign in using WHfB for the 2nd time after delta sync finished.
    • You need our support to understand why this behavior is happening and how to fix this issue.

    WHfB public key being removed from local AD user account keycredentiallink attribute directly after the user sign in successfully for the 1st time. This issue was on 2016 Domain Controller due to a missing update.

    We made sure that all 2016 domain controllers are up to date including KB4593226. Then, the issue resolved.


    hope this helps
    Wish you a happy new year

    3 people found this answer helpful.

6 additional answers

Sort by: Most helpful
  1. Nagappan Veerappan 556 Reputation points Microsoft Employee

    unless users run certutil -deleteHelloContainer. we don't delete that "msDs-KeycredentialLink" key. Also as you already aware by now. That msDs-KeycredentialLink attribute is multi valued attribute. This behavior not experienced by other customers. So I bet something specific to that machine or environment causing to loose the keys and re-provisioning back with new keys.

    Best choice is open up support case and Support can collect the appropriate logs to investigate further. 

    2 people found this answer helpful.
    0 comments No comments

  2. Brian Saville 21 Reputation points

    Same issue here. Started about the same time. No configuration changes have been made. Very small environment. I am aware of all changes. It just stopped working about 10 days ago. Spent many, many hours investigating to ensure my configuration is correct. Finally came across this thread and am having the exact same issue as reported by @_KUL in his OP. So, @Nagappan Veerappan , this is being experienced by other customers (me!). :)

    Any update?

    1 person found this answer helpful.

  3. Nagappan Veerappan 556 Reputation points Microsoft Employee

    I worked with product group and get this listed in known issues. We have this publicly document to benefit future customers.

    Hope this helps

    -Nagappan Veerappan

    1 person found this answer helpful.
    0 comments No comments

  4. Nagappan Veerappan 556 Reputation points Microsoft Employee

    Just wondering if anyone had a chance to validate and confirm if that helps @Brian Saville and @_KUL

    Happy weekend

    0 comments No comments