We're troubleshooting the domain trust issues addressed by KB5124008. Our environment is mostly Windows Server 2019 and 2022 domain controllers, with a few 2016 systems, and we don't have any Server 2025 domain controllers yet. We never intentionally enabled Machine Identity Isolation through policy, so the registry values referenced in the guidance aren't present. We've tried disabling the feature through Group Policy and directly in both relevant registry locations, then rebooting, repairing the secure channel, and resetting the computer account password.
The repair initially makes Test-ComputerSecureChannel return True, but after roughly 5–10 minutes it may start returning False again. The result seems to flip between True and False even after remediation. Since repairing a broken trust has always restored connectivity temporarily, it's difficult to tell whether the mitigation is working.
Is the mitigation supposed to make Test-ComputerSecureChannel consistently reliable, or can the PowerShell result still be incorrect or unstable afterward? Could mixed VBS settings or a security product have enabled Machine Identity Isolation even though we never deployed it through domain policy?
3 Answers
Your server mix is relevant. The guidance is aimed at systems affected by Machine Identity Isolation when they communicate with domain controllers that don’t support the required behavior. If your environment has no Server 2025 domain controllers and the feature was never intentionally configured, confirm the actual VBS and isolation state on the affected clients rather than assuming the missing registry value means the feature was never enabled.
The mitigation doesn’t necessarily repair an already-broken secure channel by itself. It allows the normal repair process to work, so you still need to run Test-ComputerSecureChannel -Repair and usually reboot when the trust is broken. Afterward, verify that the documented registry settings are actually present in the correct locations and that Group Policy isn’t restoring another configuration.
The repair does return True initially, but the result can change back to False within 5–10 minutes. We’ve applied the settings through both policy and the registry, so we’re trying to determine whether the test result itself remains unreliable.
A False result that returns after a successful repair may indicate an ongoing authentication or connectivity problem rather than the mitigation simply failing. Check the client and domain controller event logs, secure-channel and Netlogon events, DNS resolution, time synchronization, and whether a security agent is interfering with machine-account authentication. Also test against individual domain controllers, since the result may vary depending on which controller handles the request.
That’s what makes this confusing. We have mainly Server 2019 and 2022 domain controllers, with a few 2016 systems, and no 2025 functional level or controllers. The isolation policy was never deployed, although different security products were tested recently and may have changed VBS-related settings.