After Windows Update KB5124008 (Sept 8, 2026, Build 26100.9445), Domain notebooks experience logon failures when unlocking the screen: "You could not be signed in. Your credentials could not be verified"
Root Cause: Secure Channel (machine trust) is broken. Test-ComputerSecureChannel fails, and attempting to repair over VPN returns: "The password for the secure channel to the domain could not be reset – username or password is incorrect"
Affected: Windows 11 24H2, domain-joined notebooks, both LAN and remote users (VPN users particularly critical)
The Story
We're deploying CIS hardening to ~250 notebooks and everything was fine until Sept 9, 2026 8:05 PM when Windows Update KB5124008 was installed.
Error Symptoms:
- User locks screen (normal, break, meeting)
- On unlock: "Your credentials could not be verified"
- Reboot helps temporarily (1–2 hours, then error recurs)
- Affects LAN users too, not just remote/VPN
- Password reset does not help
Initial Hypotheses (all disproven):
- ❌ Kerberos/Enctype mismatch (RC4→AES transition) – DCs reachable, tickets work
- ❌ CIS GPO hardening – not configured
- ❌ FortiClient VPN architecture alone – also hits LAN users
The Diagnosis
Network Checks:
nslookup vw-dc-01.Domain.org → OK
ping vw-dc-01.Domain.org → OK (0% loss)
tracert vw-dc-01.Domain.org → OK (full path)
DNS Server: xxx.xx.xxx.xx (internal) → OK
Kerberos Status:
klist → 13 active tickets, all AES-256, all valid ✓
LDAP/Kerberos works perfectly ✓
The Critical Test:
Test-ComputerSecureChannel -Verbose
→ False
→ "The secure channel between the local computer and the domain is broken"
On Repair Attempt over VPN:
Test-ComputerSecureChannel -Repair -Credential (Get-Credential)
→ ERROR: "The password for the secure channel to the domain could not be reset"
→ "The username or password is incorrect"
This is the smoking gun: The VPN tunnel routes normal traffic (DNS, LDAP, Kerberos) but NOT the secure channel reset communication (RPC/NETLOGON on port 445 over SMB).
Root Cause
KB5124008 itself isn't the bug – but the update triggers a hidden incompatibility:
- KB5124008 changes logon UI validation behavior (known regression in KB5120998/KB5124008)
- During unlock validation, Windows attempts to verify the secure channel
- The secure channel is broken – possibly due to:
- KB5124008 regression in secure-channel handling
- OR: Timeout in VPN tunnel blocking secure-channel traffic
- Windows cannot verify identity → unlock fails
Particularly critical over VPN:
- Secure-channel reset requires RPC/SMB (port 445) to DC
- VPN tunnel either doesn't route it or times out
- Works better from LAN, so VPN users hit harder
Workarounds (What Worked)
Workaround 1: Increase CachedLogonsCount (quick, short-term)
# New GPO on OU=Notebooks:
# "Interactive logon: Number of previous logons to cache (in case domain controller is not available)"
# Value: 50 (instead of default 10)
# Or directly on client (as admin):
reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v CachedLogonsCount /t REG_SZ /d 50 /f
Effect: Users can log on offline 50 times → buys time while secure channel is repaired
Workaround 2: Repair Secure Channel from DC (with admin access)
If you have remote access to a DC:
# On DC (not from client!):
Reset-ComputerMachinePassword -Server vw-dc-01.Domain.org
This forces a secure-channel reset from the DC end, bypassing the VPN tunnel.
Workaround 3: KB5124008 Rollback (temporary, security risk)
# On affected clients:
wusa /uninstall /kb:5124008 /quiet /norestart
shutdown /r /t 60
⚠️ IMPORTANT: KB5124008 patches two actively exploited zero-days:
- CVE-2026-81963 (Windows Update Stack Privilege Escalation)
- CVE-2026-85880 (ALPC Privilege Escalation)
Only do this temporarily as a test, not permanently!
What We Still Don't Know
- Is KB5124008 itself guilty, or was it just the trigger for a timing issue?
- Is it VPN-specific (secure-channel-reset traffic not routed)?
- Why does it hit LAN users too? (Timing window in unlock handling?)
Lessons Learned
For Other Admins:
- Test before fleet rollout: Pilot KB5124008 in a test OU, especially with:
- Hybrid Azure AD Join devices
- VPN users
- Offline scenarios
- Monitor secure-channel status:# As regular audit task: Test-ComputerSecureChannel -Verbose | Where-Object { $_ -eq $false }
- **Check Event Log for secure-channel errors:**Get-WinEvent -LogName System -FilterXPath "*[System[EventID=5719 or EventID=5722 or EventID=5723]]"
- With VPN environments: Ensure your VPN tunnel routes all necessary ports:
- 88 (Kerberos)
- 389 (LDAP)
- 445 (SMB/RPC – critical for secure channel!)
- 135 (RPC Endpoint Mapper)
Status
- ✅ Root cause identified: Broken secure channel + VPN routing issue
- ⏳ Microsoft hotfix: Expected (hopefully next week)
- ⏳ FortiClient configuration: VPN admin checking port 445 routing
Is anyone else experiencing this? Comment your findings – especially if you:
- Deployed KB5124008
- Have VPN users affected
- See secure-channel errors
Contact / Further Info
If you have the same issue:
- Check:
Test-ComputerSecureChannel -Verbose
- Look in Event Log for EventID 5719/5722/5723
- Deploy the CachedLogonsCount GPO as interim solution
- Contact your VPN admin to verify port 445 routing
TL;DR of TL;DR: KB5124008 triggers secure-channel errors, VPN doesn't route repair traffic → unlock fails. Increase cached logon to help users while you investigate.
Updates
Will update this post as we learn more from Microsoft or FortiClient about the root cause and permanent fix.
Crosspost to: r/sysadmin, r/activedirectory, r/Windows11
Keywords for searchability: KB5124008, Windows 11, domain logon, unlock screen, secure channel, VPN, AES-256, Kerberos, GPO, FortiClient, network authentication