KB5124008 (26200.9445) breaks machine secure channel / domain trust — reproducible, Server 2019 DCs

Question

KB5124008 (26200.9445) breaks machine secure channel / domain trust — reproducible, Server 2019 DCs

Alex Turner 5

After installing KB5124008 (OS Build 26200.9445) on Windows 11 domain-joined workstations, affected machines lose their domain secure channel and users can no longer log on interactively. I have a deterministic reproduction (uninstall fixes it, reinstall breaks it again), confirmed on 6 machines so far, so I've paused fleet deployment.

Posting here because this looks like a possible regression and I'd like to know if anyone else is seeing it.

Environment

Clients: Windows 11, OS Build 26200.9445 (KB5124008)
DCs: Windows Server 2019 (×2), single AD domain, healthy
Deployment via WSUS + SmartDeploy

Symptoms

Interactive logon fails with "The user name or password is incorrect" using valid credentials
Cached-credential logon works when offline
Test-ComputerSecureChannel returns False ("secure channel … is broken")
nltest /sc_query:<domain> → ERROR_NO_TRUST_LSA_SECRET (1786)
DC Security log Event 4625 for the computer account (HOST$), Logon Type 3, NTLM, Status 0xC000006D, Sub-Status 0xC000006A
Network-type auth still works (net use \\DC\IPC$ with same creds); only machine-channel/interactive auth fails

Reproduction

Domain-joined Win11 machine logs on normally
Install KB5124008 → reboot → secure channel breaks, logon fails
Uninstall KB5124008 → leave domain / join workgroup → reboot → rejoin domain → reboot → fixed
- Note: Reset-ComputerMachinePassword / Test-ComputerSecureChannel -Repair was NOT enough; a full leave-and-rejoin was required
1. Reinstall KB5124008 → failure returns → same fix resolves it again

Already ruled out

Duplicate SIDs — machines have unique machine SIDs
Server 2025 DC password-rotation issue — DCs are Server 2019
DNS (nltest /dsgetdc succeeds), AD replication (repadmin /replsummary clean), time skew (<1s), account lockout (no 4740, BadLogonCount 0), DC health (dcdiag clean; Netlogon/KDC/DNS/NTDS running)

Questions

Is anyone else seeing machine secure-channel / domain-trust breakage after KB5124008 against Server 2019 DCs?
Is there a supported mitigation or hotfix to deploy KB5124008 without breaking trust?
Any known interaction between this update and Netlogon secure-channel signing/strong-key enforcement I should check on the DCs?After installing KB5124008 (OS Build 26200.9445) on Windows 11 domain-joined workstations, affected machines lose their domain secure channel and users can no longer log on interactively. I have a deterministic reproduction (uninstall fixes it, reinstall breaks it again), confirmed on 3 machines so far, so I've paused fleet deployment. Posting here because this looks like a possible regression and I'd like to know if anyone else is seeing it. Environment
- Clients: Windows 11, OS Build 26200.9445 (KB5124008)
- DCs: Windows Server 2019 (×2), single AD domain, healthy
- Deployment via WSUS + SmartDeploy
Symptoms
- Interactive logon fails with "The user name or password is incorrect" using valid credentials
- Cached-credential logon works when offline
- Test-ComputerSecureChannel returns False ("secure channel … is broken")
- nltest /sc_query:<domain> → ERROR_NO_TRUST_LSA_SECRET (1786)
- DC Security log Event 4625 for the computer account (HOST$), Logon Type 3, NTLM, Status 0xC000006D, Sub-Status 0xC000006A
- Network-type auth still works (net use \\DC\IPC$ with same creds); only machine-channel/interactive auth fails
Reproduction
1. Domain-joined Win11 machine logs on normally
2. Install KB5124008 → reboot → secure channel breaks, logon fails
3. Uninstall KB5124008 → leave domain / join workgroup → reboot → rejoin domain → reboot → fixed
  - Note: Reset-ComputerMachinePassword / Test-ComputerSecureChannel -Repair was NOT enough; a full leave-and-rejoin was required
4. Reinstall KB5124008 → failure returns → same fix resolves it again
Already ruled out
- Duplicate SIDs — machines have unique machine SIDs
- Server 2025 DC password-rotation issue — DCs are Server 2019
- DNS (nltest /dsgetdc succeeds), AD replication (repadmin /replsummary clean), time skew (<1s), account lockout (no 4740, BadLogonCount 0), DC health (dcdiag clean; Netlogon/KDC/DNS/NTDS running)
Questions
1. Is anyone else seeing machine secure-channel / domain-trust breakage after KB5124008 against Server 2019 DCs?
2. Is there a supported mitigation or hotfix to deploy KB5124008 without breaking trust?
3. Any known interaction between this update and Netlogon secure-channel signing/strong-key enforcement I should check on the DCs?

Alex Turner 5 Reputation points

2026-09-09T18:02:33.6666667+00:00

another note, after the machine lost trust, there were no log records of failed logins on the DCs. Like the request never left the machine.
Adam F 0 Reputation points

2026-09-10T08:32:18.6333333+00:00

We are seeing the same issue on Server 2022 Domain Controllers.
Alex Turner 5 Reputation points

2026-09-10T13:00:47.44+00:00

its really interesting, the workstation can successfully take the patch initially, reboot fine for a couple hours. Then after a bit all these symptoms show up. We're up to 6 machines that this happens on. 100% of our tests.

Remove the patch it works fine after a full rejoin. Add the patch back again after fixing, then it breaks immediately though, without the couple hour delay.

Answer accepted by question author

0 additional answers

Your answer

Alex Turner 5 Reputation points

2026-09-09T18:02:33.6666667+00:00

another note, after the machine lost trust, there were no log records of failed logins on the DCs. Like the request never left the machine.
Adam F 0 Reputation points

2026-09-10T08:32:18.6333333+00:00

We are seeing the same issue on Server 2022 Domain Controllers.
Alex Turner 5 Reputation points

2026-09-10T13:00:47.44+00:00

its really interesting, the workstation can successfully take the patch initially, reboot fine for a couple hours. Then after a bit all these symptoms show up. We're up to 6 machines that this happens on. 100% of our tests.

Remove the patch it works fine after a full rejoin. Add the patch back again after fixing, then it breaks immediately though, without the couple hour delay.

Answer 1

Harry Phan 30,640 Independent Advisor

Hello Alex,

You’ve done an excellent job documenting the reproduction and ruling out the usual suspects. Based on the behavior you’re describing, KB5124008 is almost certainly introducing a regression in how Windows 11 clients negotiate the Netlogon secure channel with Server 2019 domain controllers. The key indicators are the ERROR_NO_TRUST_LSA_SECRET (1786) from nltest and the fact that cached credentials still work offline, which points directly to the machine account trust relationship being broken at the LSA secret level.

Microsoft has recently hardened Netlogon secure channel requirements in cumulative updates, enforcing stronger key negotiation and signing. On Server 2019 DCs, if the client update enforces stricter requirements than the DCs advertise, the secure channel handshake fails. This explains why Reset-ComputerMachinePassword doesn’t help: the failure isn’t the password itself, but the negotiation mechanism introduced in KB5124008.

At this point, there is no supported registry-based rollback for Netlogon hardening on the client side. The only reliable mitigation is to uninstall KB5124008 until Microsoft publishes a hotfix or updated guidance. If you must keep the patch for security reasons, the alternative is to raise the DCs to Server 2022 or later, where Netlogon supports the hardened negotiation model introduced in recent Windows 11 builds. That aligns with Microsoft’s documented Netlogon enforcement timeline.

I recommend opening a case with Microsoft Support referencing KB5124008 and the secure channel regression against Server 2019 DCs. This will help escalate the issue and get an official fix or workaround published. Until then, pausing deployment of KB5124008 across your fleet is the correct move.

I hope you've found something useful here. If it helps you get more insight into the issue, it's appreciated to accept the answer. Should you have more questions, feel free to leave a message. Have a nice day!HP.

Jens G 0 Reputation points

2026-09-10T12:09:51.4466667+00:00

We are seeing the same issue here with Windows 11 25H2 Enterprise and Server 2022 Standard domain controllers.

Less than a dozen cases among at least 126 updated clients so far, so it is definitely not a general issue.

I've enabled the "Security-kerberos" eventlog and can see the following entries being logged with eventid 312.

Fehler beim Ändern des Computerkennworts
Status: 0xC000006A
Migration erforderlich: false
Richtlinie: 1
Beendigungsgrund: 2

Enabling netlogon logging using "nltest /dbflag:0x2EBFFFFF" shows the following relevant entries in the logfile:

09/10 13:48:35 [SESSION] [4876] ORIG.DOM: NlChangePassword: Calling into Kerberos.
09/10 13:48:35 [MISC] [4876] DsGetDcName function called: client PID=-1, Dom:(null) Acct:(null) Flags: RET_DNS
09/10 13:48:35 [MISC] [4876] NetpDcInitializeContext: DSGETDC_VALID_FLAGS is c3fffff1
09/10 13:48:35 [MISC] [4876] NetpDcGetName: {domain}. using cached information ( NlDcCacheEntry = 0x00000154477DFC10 )
09/10 13:48:35 [MISC] [4876] DsGetDcName: results as follows: DCName:\{domaincontroller} DCAddress:\10.13.100.73 DCAddrType:0x1 DomainName:{domain} DnsForestName:{domain} Flags:0xe003f1fc DcSiteName:Standardname-des-ersten-Standorts ClientSiteName:Standardname-des-ersten-Standorts
09/10 13:48:35 [MISC] [4876] DsGetDcName function returns 0 (client PID=-1): Dom:(null) Acct:(null) Flags: RET_DNS
09/10 13:48:35 [ERROR] [4876] NetpLdapBind: ldap_bind failed on {domaincontroller}: 49: Ungültige Anmeldeinformationen
09/10 13:48:35 [MSA] [4876] NetrEnumerateServiceAccounts: Failed to LDAP bind as SYSTEM
09/10 13:48:35 [MISC] [4876] NlWksScavenger: Can be called again in 15 minutes (0xdbba0)
09/10 13:48:57 [MISC] [5476] DsGetDcName function called: client PID=3056, Dom:(null) Acct:(null) Flags: LDAPONLY BACKGROUND RET_DNS
09/10 13:48:57 [MISC] [5476] NetpDcInitializeContext: DSGETDC_VALID_FLAGS is c3fffff1
09/10 13:48:57 [MISC] [5476] NetpDcGetName: {domain}. using cached information ( NlDcCacheEntry = 0x00000154477DF050 )
09/10 13:48:57 [MISC] [5476] DsGetDcName: results as follows: DCName:\{domaincontroller} DCAddress:\10.13.100.74 DCAddrType:0x1 DomainName:{domain} DnsForestName:{domain} Flags:0xe003f1fc DcSiteName:Standardname-des-ersten-Standorts ClientSiteName:Standardname-des-ersten-Standorts
09/10 13:48:57 [MISC] [5476] DsGetDcName function returns 0 (client PID=3056): Dom:(null) Acct:(null) Flags: LDAPONLY BACKGROUND RET_DNS
09/10 13:48:57 [SITE] [9956] DsrGetSiteName: Site name 'Standardname-des-ersten-Standorts' is old. Getting a new one from DC.
09/10 13:48:57 [MISC] [9956] NetpDcInitializeContext: DSGETDC_VALID_FLAGS is c3fffff1
09/10 13:48:57 [MAILSLOT] [9956] NetpDcPingListIp: {domain}.: Sending UDP ping to 10.13.100.73
09/10 13:48:57 [MISC] [9956] NlPingDcNameWithContext: Sent 1/1 ldap pings to {domaincontroller}
09/10 13:48:57 [MISC] [9956] NetpDcAllocateCacheEntry: new entry 0x00000154477DF920 -> DC:BSDC03 DnsDomName:{domain} Flags:0x3f1fc
09/10 13:48:57 [MISC] [9956] NlPingDcNameWithContext: {domaincontroller} responded over IP.
09/10 13:48:57 [PERF] [9956] NlSetServerClientSession: Not changing connection (00000154478423D8): "\{domaincontroller}"
ClientSession: 00000154471AD810NetpDcDerefCacheEntry: destroying entry 0x00000154477DF920
09/10 13:48:57 [MISC] [9956] DsGetDcName function called: client PID=3056, Dom:(null) Acct:(null) Flags: LDAPONLY BACKGROUND RET_DNS
09/10 13:48:57 [MISC] [9956] NetpDcInitializeContext: DSGETDC_VALID_FLAGS is c3fffff1
09/10 13:48:57 [MISC] [9956] NetpDcGetName: {domain}. using cached information ( NlDcCacheEntry = 0x00000154477DF050 )
09/10 13:48:57 [MISC] [9956] DsGetDcName: results as follows: DCName:\{domaincontroller} DCAddress:\10.13.100.74 DCAddrType:0x1 DomainName:{domain} DnsForestName:{domain} Flags:0xe003f1fc DcSiteName:Standardname-des-ersten-Standorts ClientSiteName:Standardname-des-ersten-Standorts
09/10 13:48:57 [MISC] [9956] DsGetDcName function returns 0 (client PID=3056): Dom:(null) Acct:(null) Flags: LDAPONLY BACKGROUND RET_DNS
09/10 13:48:58 [MISC] [2028] DsGetDcName function called: client PID=3056, Dom:(null) Acct:(null) Flags: LDAPONLY BACKGROUND RET_DNS
09/10 13:48:58 [MISC] [2028] NetpDcInitializeContext: DSGETDC_VALID_FLAGS is c3fffff1
09/10 13:48:58 [MISC] [2028] NetpDcGetName: {domain}. using cached information ( NlDcCacheEntry = 0x00000154477DF050 )
09/10 13:48:58 [MISC] [2028] DsGetDcName: results as follows: DCName:\{domaincontroller} DCAddress:\10.13.100.74 DCAddrType:0x1 DomainName:{domain} DnsForestName:{domain} Flags:0xe003f1fc DcSiteName:Standardname-des-ersten-Standorts ClientSiteName:Standardname-des-ersten-Standorts
09/10 13:48:58 [MISC] [2028] DsGetDcName function returns 0 (client PID=3056): Dom:(null) Acct:(null) Flags: LDAPONLY BACKGROUND RET_DNS
09/10 13:48:58 [MISC] [1252] In control handler (Opcode: 4)
09/10 13:48:58 [MISC] [1252] In control handler (Opcode: 4)
09/10 13:49:50 [MISC] [2028] DsGetDcName function called: client PID=3056, Dom:(null) Acct:(null) Flags: LDAPONLY BACKGROUND RET_DNS
09/10 13:49:50 [MISC] [2028] NetpDcInitializeContext: DSGETDC_VALID_FLAGS is c3fffff1
09/10 13:49:50 [MISC] [2028] NetpDcGetName: {domain}. using cached information ( NlDcCacheEntry = 0x00000154477DF050 )
09/10 13:49:50 [MISC] [2028] DsGetDcName: results as follows: DCName:\{domaincontroller} DCAddress:\10.13.100.74 DCAddrType:0x1 DomainName:{domain} DnsForestName:{domain} Flags:0xe003f1fc DcSiteName:Standardname-des-ersten-Standorts ClientSiteName:Standardname-des-ersten-Standorts
09/10 13:49:50 [MISC] [2028] DsGetDcName function returns 0 (client PID=3056): Dom:(null) Acct:(null) Flags: LDAPONLY BACKGROUND RET_DNS
09/10 13:49:50 [MISC] [5476] DsGetDcName function called: client PID=3056, Dom:(null) Acct:(null) Flags: LDAPONLY BACKGROUND RET_DNS
09/10 13:49:50 [MISC] [5476] NetpDcInitializeContext: DSGETDC_VALID_FLAGS is c3fffff1
09/10 13:49:50 [MISC] [5476] NetpDcGetName: {domain}. using cached information ( NlDcCacheEntry = 0x00000154477DF050 )
09/10 13:49:50 [MISC] [5476] DsGetDcName: results as follows: DCName:\{domaincontroller} DCAddress:\10.13.100.74 DCAddrType:0x1 DomainName:{domain} DnsForestName:{domain} Flags:0xe003f1fc DcSiteName:Standardname-des-ersten-Standorts ClientSiteName:Standardname-des-ersten-Standorts
09/10 13:49:50 [MISC] [5476] DsGetDcName function returns 0 (client PID=3056): Dom:(null) Acct:(null) Flags: LDAPONLY BACKGROUND RET_DNS
09/10 13:49:53 [CRITICAL] [4876] NlMainLoop: Registry changed

As you can see the client is trying to update its password against AD, but fails .. because the old one is wrong?

The only way to fix this we've found so far is removing the client from the domain and rejoining it.

The following command does not work:

Test-ComputerSecureChannel -Repair -Credential (Get-Credential)
Alex Turner 5 Reputation points

2026-09-10T13:02:10.3266667+00:00

This may sound silly but I dont know how to open a case with microsoft. I dont think we have appropriate licensing to do so.

Jens G 0

I can now at least reproduce the underlying issue with the following command:

Reset-ComputerMachinePassword -Server {domaincontroller} -Verbose

Getting the following output:

AUSFÜHRLICH: Ausführen des Vorgangs "Reset-ComputerMachinePassword" für das Ziel "{computername}".
Reset-ComputerMachinePassword : Das Kennwort des sicheren Kanals für das Computerkonto konnte in der Domäne nicht zurückgesetzt werden. Fehler beim Vorgang mit der folgenden Ausnahme:
Der Benutzername oder das Kennwort ist falsch.

In Zeile:1 Zeichen:1
+ Reset-ComputerMachinePassword -Server {domaincontroller} -V ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OperationStopped: ({computername}:String) [Reset-ComputerMachinePassword], InvalidOperationException
    + FullyQualifiedErrorId : FailToResetPasswordOnDomain,Microsoft.PowerShell.Commands.ResetComputerMachinePasswordCommand

"Der Benutzername oder das Kennwort ist falsch." just says "Account name or password is wrong", so basically just the same as 0xC000006A.