We're troubleshooting the domain trust problems described in 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 or a 2025 domain functional level. We never intentionally enabled Machine Identity Isolation, so the registry values mentioned in the guidance don't exist. I've tried disabling the feature through Group Policy and by setting the registry values directly in both relevant locations.
After rebooting, repairing the secure channel, and sometimes resetting the computer account password, Test-ComputerSecureChannel returns True initially. However, after roughly 5–10 minutes it may start returning False again. The result seems to alternate between True and False even after the mitigation and a reboot. We also have a mixture of VBS settings across devices and have recently evaluated several security products, so it's possible another security tool changed or enabled something related to this feature.
When a computer is already affected, applying the mitigation appears to require repairing the secure channel and rebooting, which temporarily fixes the issue anyway. That makes it difficult to determine whether the mitigation is working. Is the remediation expected to make Test-ComputerSecureChannel consistently reliable, or can the PowerShell result remain broken even after the mitigation is applied?
3 Answers
A delayed transition from True back to False points to more than a stale PowerShell result. I’d compare the affected computer’s secure-channel status against the domain controller it is using, check whether DNS or site discovery is sending it between controllers, and review Netlogon and authentication events around the time the status changes. Also confirm that every relevant domain controller has received the intended updates and configuration. A mixed controller environment can make the behavior appear intermittent if different controllers handle successive authentication attempts.
The mitigation is meant to prevent the condition from recurring; it does not necessarily repair an already-broken secure channel by itself. For an affected machine, you still need to repair the trust relationship, such as with Test-ComputerSecureChannel -Repair, and then reboot. After that, verify that the documented registry settings are actually present and applied in the correct locations. If the command returns True and later changes back to False, that suggests the underlying cause is still active rather than the mitigation merely changing the command’s output.
The guidance appears to target systems that had Machine Identity Isolation enabled, especially when they communicate with domain controllers that don’t support the required behavior. Since your environment has mainly 2016–2022 domain controllers and no Server 2025 controllers, disabling the feature may be appropriate if it was enabled anywhere. However, the absence of an explicitly deployed policy does not prove it was never enabled—security software, VBS configuration, imaging, or a previous security evaluation could have changed related settings.
We never enabled it through an intentional policy, but the devices have inconsistent VBS settings. We’ve also tested several security products recently, so one of those may have modified the configuration.
That’s what makes this difficult to validate. The repair makes the command return True, but it can switch back to False five or ten minutes later. I’ve tried both Group Policy and direct registry changes in both locations.