Table of Contents
The message appears at the logon screen when a Windows 10/11 client or a Windows Server 2019/2022/2025 member server can no longer authenticate its own computer account to a domain controller. Each computer has a machine password that rotates every 30 days by default; if the value stored locally and the value in Active Directory drift apart, the secure channel fails and only cached or local accounts can log on. The usual causes are restoring a VM snapshot or backup taken before a password change, cloning a machine without sysprep, a duplicate computer name, or someone resetting the computer object in AD.
Short answer: Log on with a local administrator account, open an elevated PowerShell and run Test-ComputerSecureChannel -Repair -Credential DOMAIN\admin to reset the machine password on both sides in one step. If that fails, run Reset-ComputerMachinePassword -Server dc01 -Credential DOMAIN\admin and reboot. Rejoining the domain works too, but it is slower, generates a new SID for the computer object and can break group memberships and GPO links, so keep it as the fallback.
Confirm it really is the secure channel
Sign in with a local account, or disconnect the network cable and sign in with the last domain user, whose credentials are cached. Then check the channel state in an elevated PowerShell:
Test-ComputerSecureChannel -Verbose
nltest /sc_query:corp.example.comA result of False, or an nltest status such as ERROR_NO_TRUST_SAM_ACCOUNT or ERROR_NO_LOGON_SERVERS, confirms the diagnosis. If nltest reports no logon servers, fix DNS and connectivity first; the machine may simply be unable to reach a DC, and repairing the password will not help. Check that the client’s DNS points only at domain controllers and that nslookup -type=SRV _ldap._tcp.dc._msdcs.corp.example.com returns records.
Repair the secure channel in place
The repair option reads the current computer account in AD and resets the password on both sides:
Test-ComputerSecureChannel -Repair -Credential (Get-Credential CORP\adminuser)Use a domain account that has “Reset password” rights on the computer object, which any Domain Admin or a delegated helpdesk group will have. When the command returns True, reboot and sign in with a domain account. If it returns an access denied error, the computer object may be disabled or missing. Check with:
Get-ADComputer PC-FINANCE-07 -Properties Enabled, PasswordLastSet, LastLogonDateRe-enable it with Enable-ADAccount if needed. If the object was deleted, restore it from the Active Directory Recycle Bin rather than recreating it, so the SID and memberships survive.
Use Reset-ComputerMachinePassword when repair fails
This cmdlet writes a fresh password directly against a named DC, which avoids replication delays across sites:
Reset-ComputerMachinePassword -Server dc01.corp.example.com -Credential CORP\adminuser
Restart-ComputerOn older systems without the AD PowerShell module the equivalent is netdom resetpwd /server:dc01 /userd:CORP\adminuser /passwordd:*. Both commands require the machine to reach the DC on TCP 445 and 135, so a host firewall or a VPN client that only allows DNS traffic will make them fail with an RPC error.
Stop it coming back
If the same machine breaks repeatedly, find the reason rather than repeating the repair:
- Snapshots: on VMware and Hyper-V, revert-to-snapshot restores an old machine password. Either avoid keeping snapshots for more than 30 days or disable the rotation on lab machines with the GPO Computer Configuration » Policies » Windows Settings » Security Settings » Local Policies » Security Options » “Domain member: Disable machine account password changes”.
- Cloning: run
sysprep /generalizebefore cloning, or every clone shares one computer SID and account. - Duplicate names: two machines with the same name overwrite each other’s password. Rename one.
- Backup restores of a DC: a DC restored from an image older than the tombstone lifetime causes USN rollback (Event ID 2095), which breaks trust on many machines at once; see fix AD replication errors 8453 and 1722 for the wider checks.
The rotation interval itself is controlled by the “Domain member: Maximum machine account password age” policy, 30 days by default. Do not extend it as a workaround unless the environment genuinely needs long-lived snapshots.
Verify
Log on as a domain user without the cable unplugged, then run Test-ComputerSecureChannel again and expect True. On the DC, check the computer object shows a fresh PasswordLastSet value and that Event ID 5723 or 5805 (NETLOGON failures) no longer appear in the System log.
Trust relationship failed at a glance
Official documentation: Active Directory Domain Services docs, Windows Server documentation.
Related guides: Raise the AD forest and domain functional level safely · How to find the source of Active Directory account lockouts (Event ID 4740) · Configure NTP time sync for the PDC emulator and domain clients.
Frequently asked questions
Does the trust relationship error also affect servers or only workstations?
It affects any domain member, including Windows Server 2019/2022/2025 member servers, and the same repair commands work; on a server, sign in with the local administrator or use a remote PowerShell session from a DC.
How long does repairing the trust relationship take?
The command itself completes in seconds; including the reboot, a machine is usually back in service within five minutes, compared with 15 to 20 minutes for a full leave and rejoin.
Can I undo the repair or does it change anything permanent?
There is nothing to undo; the command simply sets a new machine password on both the client and AD, the computer’s SID, GUID and group memberships are unchanged, and no GPO links are affected.