Finding Why a Windows Domain Trust Relationship Keeps Failing

A domain-joined Windows 11 machine that loses its secure channel shows the sign-in message "The trust relationship between this workstation and the primary domain failed." Cached credentials often still work, so the problem shows up first as users who can't sign in after a restart or a password change. Since the September 8, 2026 security update, this has a known cause on some machines, and it can also come back after the known fix is applied. This post covers how to find which of those you have with tools that ship with Windows and Active Directory.

Check the known issue first

Microsoft lists this as a known issue for Windows 11 versions 24H2, 25H2, 26H1, and 26H2 on the Windows release health page (Windows 11, version 24H2 known issues). KB5124008 and later updates cause Windows to honor existing Machine Identity Isolation settings, and Microsoft says that feature is supported only with domain controllers at a Windows Server 2025 domain functional level. Machines with Credential Guard protected machine accounts and older domain controllers can lose their secure channel.

Read the two registry values on an affected machine from an elevated PowerShell prompt.

Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa' -Name MachineIdentityIsolation -ErrorAction SilentlyContinue
Get-ItemProperty 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\DeviceGuard' -Name MachineIdentityIsolation -ErrorAction SilentlyContinue

A value of 2 is enforcement mode. Disable the setting with the same method that enabled it. For Group Policy that is "Turn On Virtualization Based Security" under Computer Configuration\Administrative Templates\System\Device Guard. Run gpresult /h gp.html to find which GPO sets it. For Intune it is the DeviceGuard MachineIdentityIsolation policy. Set the value to 0, restart, and repair the channel.

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

If both values are 0 or absent and the machine still fails, the cause is somewhere else. The rest of this post assumes that case.

Log which domain controller each result comes from

A secure channel that passes one minute and fails the next can depend on which domain controller the client is talking to at that moment. Test-ComputerSecureChannel accepts a -Server parameter, so you can test the channel against each domain controller by name and record the result. List your domain controllers with nltest /dclist:YOURDOMAIN, put their names in the script below, and run it in an elevated PowerShell window on an affected machine.

$dcs = 'DC-NAME-1','DC-NAME-2','DC-NAME-3'
while ($true) {
    foreach ($dc in $dcs) {
        $ok = Test-ComputerSecureChannel -Server $dc
        "{0:u} {1} {2}" -f (Get-Date), $dc, $ok | Add-Content C:\Temp\securechannel.log
    }
    Start-Sleep -Seconds 60
}

Also run nltest /sc_query:YOURDOMAIN when a user reports a failed sign-in. The "Trusted DC Name" line gives the domain controller the Netlogon service is using right now, and "Trusted DC Connection Status" gives the result of the last use of the channel.

After an hour, open securechannel.log. When every False result comes from one or two domain controllers, it's likely that those domain controllers hold a different machine account password than the client. When False results come from every domain controller at the same times, look at the client itself.

Compare the computer account on every domain controller

Get the distinguished name of the affected computer account, then show its replication metadata on every domain controller.

Get-ADComputer AFFECTED-PC | Select-Object DistinguishedName
repadmin /showobjmeta * "CN=AFFECTED-PC,OU=Workstations,DC=yourdomain,DC=local"

Find the pwdLastSet and unicodePwd rows in each domain controller's output. Each row gives the version number, the originating domain controller, and the time of the last change. A domain controller that shows a lower version than the others has not received the latest password change. Run repadmin /showrepl on that domain controller and fix the replication error it reports before you repair any more clients.

Read the Netlogon events on both sides

On the client, filter the System log for Netlogon event 5719.

Get-WinEvent -FilterHashtable @{
    LogName = 'System'
    ProviderName = 'NETLOGON'
    Id = 5719
} -MaxEvents 20 | Format-List TimeCreated, Message

The message reads "This computer was not able to set up a secure session with a domain controller in domain" followed by the domain name and the error. Match the times against the False results in securechannel.log.

On the domain controllers that returned False, filter the System log for Netlogon event 5722. The message reads "The session setup from the computer" followed by the computer name, then "failed to authenticate" and the error. Microsoft documents that 5722 is also logged when a computer updates its own password, and in that case the channel is still valid. Count only the 5722 events whose times match a False result from that domain controller (Event ID 5722 is logged on a domain controller).

Turn on Netlogon debug logging

When the events don't explain the failures, turn on Netlogon debug logging on the client from an administrative command prompt.

nltest /dbflag:0x2080ffff

The log is written to C:\Windows\debug\netlogon.log. Wait for the next False result in securechannel.log, then read the netlogon.log lines with the same timestamp. Each session setup attempt names the domain controller it tried and the status it got back. Turn the logging off when you have the lines you need.

nltest /dbflag:0x0

Repair the channel once the cause is fixed

When the failures come from one domain controller, fix that domain controller's replication first. Then run Test-ComputerSecureChannel -Repair -Credential (Get-Credential) on each affected client and let the logging script run for another hour. A full hour of True results from every domain controller means the channel is stable. When the failures come from every domain controller, check the Machine Identity Isolation values again, because a GPO or Intune policy that still sets them will set them back to 2 at the next refresh.

Where ET Ducky fits

I build ET Ducky. You'd start a Multi-Agent Session across the affected clients and the domain controllers they authenticate against. Multi-Agent Sessions ingest the sequence of events that occur as each agent in the session attempts the process, then correlate the results that are reported from each to determine what systemic issue may be occurring. The multi-agent troubleshooting post walks through a session across four machines.