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

Question

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

Alex Turner 60

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) - 25H2
DCs: Windows Server 2019 (×2), single AD domain, healthy - running August patches
- Active Directory Domain Services functional level -Windows Server 2016 functional level
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?

--Update 9/14/2026 ---
Using the advice from very helpful answers below we now have a mitigation path. Our machine identity isolation was enabled in enforcement mode.

Screenshot here is what causes the failure.
User's image

We took advice from answers below and set it to disabled (0) both on the GPO and intune baseline security configuration.

User's image

We also configured the GPO to disabled but that didnt seem to set the value very well on the machine itself. We ended up also forcing 0 on the registry key.

User's image

We plan to revisit this next month and test enforcing it again after patching in October.

Alex Turner 60 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 15 Reputation points

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

We are seeing the same issue on Server 2022 Domain Controllers.
Alex Turner 60 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.
Alex Turner 60 Reputation points

2026-09-10T14:22:27.5233333+00:00

more info, we have not patched domain controllers. We patch workstations first and wait until the following weekend for domain controllers.

We've been patching non critical servers and they seem to be fine.
Adam F 15 Reputation points

2026-09-11T01:49:46.79+00:00

We have patched our 2022 DCs; has made little difference for the clients. They still have trust issues when KB5124008 is installed.
MeierS 0 Reputation points

2026-09-11T09:26:51.4466667+00:00

We’ve been seeing domain trust / secure channel issues with fully patched Windows 11 clients across multiple customers, most of them starting with the july security updates. So far we’ve had cases with 2016 / 2019 / 2022 and 2025 domain controllers. Test-ComputerSecureChannel -Repair usually does the trick, but never permanently. The secure channel issues only seem to affect as small number of devices, but keeps coming back to the same machines. I haven’t been able to figure out why only some systems are affected while others are not. Most of our clients have identical machines in terms of hardware and are deployed using sccm or similar software.

I have seen the issue with KB5124008 on three out of ten machines just this morning, altough Test-ComputerSecureChannel -Repair was sufficient to fix it for now without a full leave-and-rejoin
cmacrun 0 Reputation points

2026-09-14T19:23:19.0233333+00:00

Has anyone with this issue had a chance to test the OOB that was just released to see if it corrects the behavior?

https://support.microsoft.com/en-us/servicing/os/windows-11/2026/09/kb5129195-windows-11-24h2-25h2-security-update
Harris, Taylor 0 Reputation points

2026-09-15T15:49:53.0466667+00:00

I've installed the latest OOB patch on a machine that hadn't yet been patched and excluded from receiving our configuration to disable Machine Identity Isolation, and the issue still remains with the LSA secret getting discarded, so you still have to disable Machine Identity Isolation, then reset the machine password and repair the secure channel to fix everything with the patch in place.

The OOB patch does however fix the issue with the Virtual Machine Platform service breaking WSL folder access (Claude Cowork in particular was an affected app in our case).

Answer accepted by question author

Marcel Zehnder 90

I have had the exact same problem with the first machine that recieved KB5124008. Every few minutes and after each reboot the secure channel got lost. With the help of ChatGPT I could fix it by changing the registry value HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MachineIdentityIsolation from 2 to 0.

After a reboot, I had to restore the secure channel by 'Test-ComputerSecureChannel -Repair -Credential(Get-Credential)'. Since then, the computer is running without loosing the secure channel anymore.

Adam F 15 Reputation points

2026-09-11T06:40:36.7+00:00

Having that registry key set to "2" seems very deliberate.

Hopefully you don't have a GPO that's going to change it back at some point.
Marcel Zehnder 90 Reputation points

2026-09-11T07:27:09.43+00:00

No, we have no GPO on that entry, so it's difficult to explain why the key was set to 2.
MNM Show 16 Reputation points

2026-09-11T20:39:52.8966667+00:00

This issue has not been hitting my org and I have been trying to understand why. Based on what I am reading I think it is almost certainly the machine identity isolation setting. The GPO path is Computer Configuration\Administrative Templates\System\Device Guard\Turn On Virtualization Based Security and in my org I have this explicitly set to enabled with the Credential Guard Configuration: explicitly set to disabled. The registry path for this is Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\DeviceGuard which I am given to understand might have no visible keys if the GPO setting for Turn on Virtualization Based Security is not enabled. Since I do have that enabled, I see keys here including LsaCfgFlags set to 0 which is indicative of credential guard being disabled. I had disabled this some time ago because it was breaking some SSO functions. It had been on my mind to examine re-enabling it for the security posture improvements, but I have other mitigations for Pass the Hash and other attacks that this feature helps address so it hadn't been a priority.

Interestingly, in that registry path, I also see MachineIdentityIsolation set to 3 which is an invalid value. I believe this is related to the disablement MS applied in the April 2025 updates as mentioned here: https://support.microsoft.com/en-us/servicing/os/windows-11/2025/04/april-8-2025-kb5055523-os-build-26100-3775

I also suspect a GPO setting that enables Turn on Virtualization Based Security and also explicitly enables Credential Guard Configuration: would still not cause the problem as long as Machine Identity Isolation Configuration: was explicitly disabled. I don't know if a GPO enabling credential guard alone would change that value of 3 for MachineIdentityIsolation but it sounds as if a GPO setting a 1 or 2 (either audit or enabled) is a trust breaking problem.

As MS notes here: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/delegated-managed-service-accounts/credential-guard-protected-machine-accounts if you had MachineIdentityIsolation explicitly enabled, disabling it will still require a domain unjoin and rejoin.
Niki Serup 5 Reputation points

2026-09-14T09:23:54.22+00:00
The Machine Identity Isolation setting was the culprit in our domain.

MachineIdentityIsolation was set to 1 (Audit).

Marcel Zehnder's workaround did the trick for us.

Asked the user to unplug dock/lan and disable Wifi.

Login using cached credentials.

Connect the dock to the computer, and check the device is getting a IP.

Connect to the computer using "Remote Control Viewer".

Use LAPS to edit the MachineIdentityIsolation from 1 -> 0.

Test-ComputerSecureChannel -Repair -Credential(Get-Credential)

Restart the computer - now the user can login normally
Alex Turner 60 Reputation points

2026-09-14T16:32:21.9166667+00:00

This was the trick for us! Thanks for solving this one!
Harris, Taylor 0 Reputation points

2026-09-14T16:50:53.6433333+00:00
Just wanted to report as a system admin from another organization that the changes introduced in KB5124008 concerning Machine Identity Isolation in Credential Guard breaks Windows 11 25H2 domain trust in the same manner as thoroughly detailed by the OP, Alex Turner, as well as all others who have detailed NTLM/NETLOGON failures on this thread.

This was rolled out to a pilot sample rather our entire organization of only ~50 or so machines on the evening of Thursday, 9/10/2026, but every machine that installed KB5124008 and completed the post-installation reboot had NETLOGON failures and had to have their domain trust repaired by the following Friday morning (9/11/26).

We've been following this thread since then and can also confirm that the MachineIdentiyIsolation value in the registry was set to 2 post-update (Enabled with enforcement), and disabling the feature (which corresponds to a value of 0) has proven to enable our machines to stop discarding the machine account LSA secret without having to uninstall the security patch. Some confusing aspects about this subject, however:

While we had a GPO configured for our workstations to enable Virtualization Based Security along with Credential Guard, we never configured Machine Identity Isolation in the policy, and while I don't even recall the setting when I was last in the policy months ago, I know for a fact it was left as "Not Configured", and certainly not "Enabled WITH ENFORCEMENT", as we made sure not to enable any of the enforcement or UEFI "lockout" options on the VBS setting. While it makes sense that if left to "Not Configured", the patch could have enabled this setting to the '2' toggle (with enforcement) and introduced this behavior without the GPO configured to enforce otherwise, we're struggling to grasp how our GPO could have been modified to reflect this configuration when we're certain we never enabled it, and can confirm when we last modified the GPO and what we enabled it to do. The only thing I can conceive that might be of significance is updating the latest ADMX templates on our DC's several weeks ago to keep them current, and somehow the updated settings schema imposes a default option for certain items where previous set to "Not Configured", but this is a complete guess.

I changed our GPO to set this to "Disabled" so it would effectively make the registry value mentioned correspond to 0 on all of our machines (so any change to the MachineIdentityIsolation setting/value in our case was done by setting the GPO to Disabled, not direct registry modification)

The other strange aspect about this registry key is that, while the value changed to 0 after applying the GPO with the "Disabled" setting as expected, the two machines we uninstalled this patch from and rebooted still reflect a registry value of '2'! They're receiving the same GPO that's configuring the value to be 0 on all other machines, but this value is remaining '2' exclusively on the machines that KB5124008 has been removed from, almost as if this setting isn't recognized if on earlier builds of Windows than this patch and it's just being left in place and not really having any effect.

Somehow, I was able to deploy this workaround via GPO and repair all of the affected machines remotely without ever having to unjoin/rejoin them to the domain or reboot them. For anyone else who might be in the same situation, this is essentially what we were able to do to repair the machines with the patch left installed using automation:

Set a Group Policy configuration to define the "Machine Identity Isolation" setting inside of the "Virtualization Based Security" setting under Computer Configuration>Policies>Administrative Templates>System>Device Guard as 'Disabled'.

Assuming you're able to use administrative credentials to run WinRM/PowerShell Remoting commands to the machines (in our case, we were, which is strange considering the domain trust was failing, but somehow NTLM was authenticating for single hop, client-to-client connections), run the following against the affected machines:
Invoke-Command -ComputerName ($yourListOfMachines) -Credential $credWithAdminAccess -ScriptBlock { # Run a GPUpdate to ensure that the GPO change to disable Machine Identity Isolation takes effect gpudate /force # Reset the machine's secure LSA password (this command fails until MachineIdentityIsolation is disabled) Reset-ComputerMachinePassword -Server $yourDomainController -Credential $using:credWithAdminAccess # Repair the computer secure channel (with the updated LSA-stored machine password in place Test-ComputerSecureChannel -Server $yourDomainController -Credential $using:credWithAdminAccess -Repair }

We've found that using "Test-ComputerSecureChannel" to merely check if the domain trust is fixed to be unreliable, as after repairing the trust on all machines, we would randomly see some machines come back as false when checking again, then checking again right after, those machines would report "True" and some different machines would report "False". This seems to be erratic behavior inherent to the PowerShell cmdlet.

To accurately verify no secure channel issues exist, I ran the nltest.exe /sc_verify:$yourDomainController command to ensure I got back a success.

Why a reboot wasn't necessary for the GPO change to the MachineIdentityIsolation setting to be effective, I don't know, and why internal, machine-to-machine authentication seemed to work most of the time to enable us to remotely issue these commands, I also don't know, but this has at least restored order to the machines we have installed the patch on without having to remove it.

All of this being done, we have a case opened with Microsoft on it, giving them event logs detailing the before and after states from the patch of the Netlogon-Security component, as well as the results of altering this Credential Guard feature and how it seems related to the issue at hand. We're still waiting to hear back from them or even see them add this to their known issues on the patch's official page. Despite finding a "workaround" (that we don't fully understand or know what the long-term consequence of using could be), we have paused patch deployment to further PC's.

Thanks to everyone else who has shared the information found here, and I hope our findings will be helpful to someone as well until Microsoft finally confirms this.

3 additional answers

Your answer

Alex Turner 60 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 15 Reputation points

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

We are seeing the same issue on Server 2022 Domain Controllers.
Alex Turner 60 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.
Alex Turner 60 Reputation points

2026-09-10T14:22:27.5233333+00:00

more info, we have not patched domain controllers. We patch workstations first and wait until the following weekend for domain controllers.

We've been patching non critical servers and they seem to be fine.
Adam F 15 Reputation points

2026-09-11T01:49:46.79+00:00

We have patched our 2022 DCs; has made little difference for the clients. They still have trust issues when KB5124008 is installed.
MeierS 0 Reputation points

2026-09-11T09:26:51.4466667+00:00

We’ve been seeing domain trust / secure channel issues with fully patched Windows 11 clients across multiple customers, most of them starting with the july security updates. So far we’ve had cases with 2016 / 2019 / 2022 and 2025 domain controllers. Test-ComputerSecureChannel -Repair usually does the trick, but never permanently. The secure channel issues only seem to affect as small number of devices, but keeps coming back to the same machines. I haven’t been able to figure out why only some systems are affected while others are not. Most of our clients have identical machines in terms of hardware and are deployed using sccm or similar software.

I have seen the issue with KB5124008 on three out of ten machines just this morning, altough Test-ComputerSecureChannel -Repair was sufficient to fix it for now without a full leave-and-rejoin
cmacrun 0 Reputation points

2026-09-14T19:23:19.0233333+00:00

Has anyone with this issue had a chance to test the OOB that was just released to see if it corrects the behavior?

https://support.microsoft.com/en-us/servicing/os/windows-11/2026/09/kb5129195-windows-11-24h2-25h2-security-update
Harris, Taylor 0 Reputation points

2026-09-15T15:49:53.0466667+00:00

I've installed the latest OOB patch on a machine that hadn't yet been patched and excluded from receiving our configuration to disable Machine Identity Isolation, and the issue still remains with the LSA secret getting discarded, so you still have to disable Machine Identity Isolation, then reset the machine password and repair the secure channel to fix everything with the patch in place.

The OOB patch does however fix the issue with the Virtual Machine Platform service breaking WSL folder access (Claude Cowork in particular was an affected app in our case).
Adam F 15 Reputation points

2026-09-11T06:40:36.7+00:00

Having that registry key set to "2" seems very deliberate.

Hopefully you don't have a GPO that's going to change it back at some point.
Marcel Zehnder 90 Reputation points

2026-09-11T07:27:09.43+00:00

No, we have no GPO on that entry, so it's difficult to explain why the key was set to 2.
Niki Serup 5 Reputation points

2026-09-14T09:23:54.22+00:00

The Machine Identity Isolation setting was the culprit in our domain.

MachineIdentityIsolation was set to 1 (Audit).

Marcel Zehnder's workaround did the trick for us.

Asked the user to unplug dock/lan and disable Wifi.

Login using cached credentials.

Connect the dock to the computer, and check the device is getting a IP.

Connect to the computer using "Remote Control Viewer".

Use LAPS to edit the MachineIdentityIsolation from 1 -> 0.

Test-ComputerSecureChannel -Repair -Credential(Get-Credential)

Restart the computer - now the user can login normally
Alex Turner 60 Reputation points

2026-09-14T16:32:21.9166667+00:00

This was the trick for us! Thanks for solving this one!

Answer 1

Harry Phan 31,295 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 10 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 60 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. We dont pay for Microsoft premier support so i dont know how to actually tell them about the issue.

Jens G 10

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.

Answer 2

Gabriel Burcusel 0

Today it hit me aswell.. Secure channel trust broken for several clients, but "Machine Identity Isolation" is not enabled on my environment. I had to use the laps admin to log on the affected clients and run the repair powershell command.

Really annoying and frustrating, found this article only after spending several hours finding the cause and solution.

0 comments

Answer 3

Jim Iversen 0

Not sure if this has any impact on what's going on with this KB...

Windows 10 Pro 25H2, build 26200.9445 with Security Update KB5124008 NT AUTHORITY\SYSTEM 9/10/2026 12:00:00 AM installed.

Test-ComputerSecureChannel returns True.

DC's are a mix of 2019 and 2022.

Workstation logon is using Okta Verify with YubiKey Security Token. Not having any issues yet.

0 comments