After installing Windows 11 update KB5124008 on domain-joined 24H2 notebooks, users began seeing "You could not be signed in. Your credentials could not be verified" when unlocking their screens. Rebooting temporarily helps, but the problem returns after an hour or two. It affects both LAN and VPN users, with remote users experiencing the most difficulty.
DNS, connectivity, LDAP, and Kerberos appear healthy: domain controllers resolve and respond, network paths complete successfully, and klist shows valid AES-256 tickets. However, Test-ComputerSecureChannel -Verbose reports that the machine's secure channel is broken. Attempts to repair it over VPN fail with an error saying the secure-channel password could not be reset and that the username or password is incorrect.
The likely issue is a broken computer account trust combined with VPN restrictions or timeouts affecting the RPC and SMB traffic needed to reset the secure channel. The update may have exposed or triggered the problem during unlock validation, but it is not yet clear whether KB5124008 is the direct cause.
As temporary measures, administrators have increased CachedLogonsCount so users can authenticate offline while repairs are pending, reset the machine password from the domain-controller side, or temporarily removed the update for testing. Removing the update should be treated cautiously because it contains important security fixes. VPN administrators should also verify that the required domain traffic, including Kerberos, LDAP, SMB, and RPC, is supported. Has anyone else seen this combination of KB5124008, unlock failures, and broken secure channels?
2 Answers
I have seen the same general failure after deploying this update, including systems where ordinary network checks and Kerberos tickets looked fine. The useful distinction was that Test-ComputerSecureChannel failed. Resetting the machine password from the domain-controller side worked better than trying to repair it through the VPN. I would verify RPC/SMB reachability and review System events 5719, 5722, and 5723 before blaming an encryption or password issue.
The CachedLogonsCount workaround is easy to misunderstand. The value is the number of different domain users whose credentials Windows can cache, not the number of times one user can unlock or log on. Setting it to 50 may let more previously used accounts authenticate while the domain controller is unavailable, but it does not repair the secure channel or solve the underlying problem.
Related Questions
Can't Load PhpMyadmin On After Server Update
Redirect www to non-www in Apache Conf
How To Check If Your SSL Cert Is SHA 1
Windows TrackPad Gestures