"The Trust Relationship Failed" After a Member Server Restore: Prove the Secure Channel and Repair It in Place

Direct answer: When a domain-member server comes back from a restore or a snapshot revert and domain users get "The trust relationship between this workstation and the primary domain failed", the usual cause is that the server's own copy of its computer account password no longer matches what Active Directory holds. The server changed its password (by default every 30 days) after the backup was taken; the restored image only knows older values. Gather three read-only observations, then correlate them with the computer object on the DC that refused it:

1. Event 3210 from source NETLOGON in the System log ("This computer could not authenticate with \\DC…").
2. nltest /sc_query:<domain> returning an error such as ERROR_ACCESS_DENIED instead of NERR_Success (this reports the channel as it was last used), and a current Test-ComputerSecureChannel returning False.
3. Local or cached sign-in still working while domain sign-in fails.

Then repair the secure channel in place: sign in with a local administrator account (or cached domain credentials), and run Reset-ComputerMachinePassword -Server <DC> with credentials that are allowed to reset that computer account. You do not need to remove the server from the domain and rejoin it. A rejoin is a valid fix, but it creates more work and can lose the computer object's group memberships and delegated permissions if the object is deleted and recreated.

Before you reset anything, rule out the two look-alikes: a second machine running with the same name (a clone or an un-retired original), and a domain controller that was itself restored to an older state.

Why it matters

A failed secure channel looks like a sign-in fault, and it often arrives in the middle of a recovery when people are already under pressure. The tempting reactions all cost more than the real fix:

• Leaving and rejoining the domain works, but needs a reboot (sometimes two), a local administrator password you may not have, and rights to join computers. If someone deletes the computer object first, the new object loses its group memberships, its delegated permissions and anything that referenced it by identity.
• Disabling machine password changes to "stop it happening" weakens the domain. Microsoft's guidance is to leave that policy disabled, and it has narrow legitimate uses only.
• Blaming the domain controllers sends people restoring or reseeding the wrong thing.

The faster path is to prove which side holds the newer password and repair the one machine that is out of step. Once the cause is clear, the restore runbook can include the repair step, so the next restore does not turn into an incident.

How it works

Every domain-joined Windows computer has a computer account in Active Directory with a password, just like a user account. Nobody types it; Windows generates it. The Netlogon service uses it to build the secure channel to a domain controller. That channel is what lets the member server pass domain users' sign-ins through to a DC and verify them.

Who changes the password, and when. The change is driven by the computer, not by Active Directory. By default, Netlogon on the member checks every 15 minutes (the scavenge interval) whether the password is older than the maximum machine account password age, which defaults to 30 days (policy Domain member: Maximum machine account password age, range 1–999 days in the policy UI). When it is due, the member contacts a DC, sets a new random password, and stores it locally. The DC writes it to the computer object, and normal AD replication carries it to other DCs. Machine account passwords do not "expire" in Active Directory: a computer switched off for months simply changes its password when it next reaches a DC.

What each side remembers. The member keeps two values in a protected LSA secret ($MACHINE.ACC): the current password (CurrVal) and the previous one (OldVal). When it sets up the channel and the current password is rejected, Netlogon tries the previous one; the Netlogon debug log shows this as "new password is bad, try old one". Active Directory stores the password on the computer object and records when it was set in pwdLastSet.

Why a restore breaks it. Suppose a backup captured the server on day 1. On day 20 the server changed its password, and AD now holds the new value. On day 25 you restore the day-1 image. The restored server still has the day-1 password as "current" and the one before that as "previous". If neither matches what AD now holds, the DC rejects the channel, and domain sign-ins on that server fail.

The Microsoft troubleshooting article sums up the two cases:

The first row is the subject of this article. The second has a different fix: correct the DC or replication, not the member. That is why you prove the direction before resetting anything.

How far back can a restore go and still work? Because the member keeps its previous password as well as its current one, a restore across one password change can sometimes still authenticate, depending on which value AD and the DC hold at the time. Microsoft's description is that a sequence of more than two changes can leave the computers unable to communicate. Do not plan around a precise number of days. Treat any restore older than the password age (30 days by default) as likely to need a reset, and check every restore, younger or older, with the read-only tests below.

Snapshots and clones belong to the same family. Reverting a VM snapshot is a restore for this purpose. A clone that keeps the original's name and joins the network beside it causes another symptom: two machines sharing one computer account fight over the password, and each change by one breaks the other. The Netlogon 3210 text names this possibility directly: "another computer on the same network using the same name". The Duplicate IP or MAC Address After a VM Clone or Restore: Prove It, Contain It, Fix the Copy covers duplicate identities after clone or restore; the point here is to rule it out before resetting.

Read-only checks

None of these was run for this article. They are listed in the order that gives the most evidence for the least change. Unless stated, they read state only.

Privileges: event log reads and nltest /sc_query from an elevated session on the affected server. Get-ADComputer needs only a domain account with read access to the object, plus the Active Directory PowerShell module (RSAT) on whichever machine you run it from. Run it from a working management machine, not from the broken server.

1. Confirm sign-in behaviour

Sign in with a local account, or with cached domain credentials if they exist. If local sign-in works and fresh domain sign-in fails with the trust relationship message, you have the classic pattern. Cached credentials can let a user who has signed in before get in even while the channel is broken. That does not prove the channel is healthy.

If you have no local administrator password, retrieve it from Windows LAPS if it is deployed. The Windows LAPS: Deploy It Safely and Recover the Local Administrator After a Restore covers LAPS recovery. If LAPS rotated the password after the backup point, the value currently stored in the directory may not match the restored image. F20 explains how to recover the password that matches.

2. Read the Netlogon evidence

# On the affected server, elevated. Reads the System log only.
Get-WinEvent -FilterHashtable @{ LogName = 'System'; ProviderName = 'NETLOGON'; Id = 3210 } -MaxEvents 20 |
    Format-List TimeCreated, Message

Event 3210 says the computer "could not authenticate with \\DCName…, a Windows domain controller for domain …" and suggests either a duplicate name or an unrecognised password. Note which DC it names and the first time it appears relative to the restore.

3. Query the secure channel state

nltest /sc_query:contoso.com

/sc_query reports the state of the secure channel the last time it was used and which DC it was using. A healthy result normally shows a trusted DC name and a connection status of NERR_Success (status 0); the exact layout varies by version. In the broken state Microsoft documents, the status is 5 0x5 ERROR_ACCESS_DENIED and the trusted DC name is blank.

Test-ComputerSecureChannel without parameters returns $true or $false and adds detail with -Verbose:

Test-ComputerSecureChannel -Verbose

Both of these query; neither changes anything. Do not run the variants that repair while you are still collecting evidence:

Microsoft notes that Test-ComputerSecureChannel is meant for member computers and can give misleading results on domain controllers; use other tools there.

4. Compare the two sides' password dates

From a working management machine, read when AD last recorded a password for this computer:

# Read-only: reads attributes of one computer object.
# Query the DC named in event 3210, and one other DC for comparison.
Get-ADComputer -Identity SERVER01 -Server <DC-from-3210> -Properties pwdLastSet, PasswordLastSet, whenChanged, Enabled |
    Select-Object Name, Enabled, PasswordLastSet, whenChanged

Compare PasswordLastSet with the date the backup or snapshot was taken. The backup date is supporting evidence, not the member's own password-update time (that is cupdtime, below), and an AD date newer than the backup does not on its own prove that neither of the member's two stored passwords would be accepted.

• If AD's date is later than the backup point, and the DC from 3210 shows the same value as the other DC, and a current read-only channel test (step 3, Test-ComputerSecureChannel -Server <DC-from-3210>) fails, and no DC has been restored recently, the evidence points to the first scenario: reset the member.
• If AD's date is earlier than or equal to the backup point, or the two DCs disagree, and you still see 3210, look at the other row of the table above (a DC restored to an older state, or replication delay; repadmin /showrepl <DC> is a read-only check). Also look at duplicate names.

Microsoft's troubleshooting series compares this value with the member's local cupdtime (the last update time of the stored machine password, held under the protected HKLM\SECURITY\Policy\Secrets key). Reading that key requires running as SYSTEM. It is useful for deep diagnosis, but for a restore you already know the image date, and you should not need to read secrets to make this decision.

Also confirm Enabled is True. A disabled, deleted or recreated computer object produces a similar failure, and the fix there is to restore or re-enable the object, not to reset a password.

5. Rule out a duplicate name

A clone, an old VM left powered on, or the "original" server brought back beside its restored copy will keep breaking the channel after every reset. Check that only one live machine answers to the name and IP address. DNS records, the hypervisor inventory and the switch or DHCP tables are good places to look; the duplicate-identity article (F16) covers this in detail. Also check the hostname registry values that Microsoft mentions: the computer name must be the short name, not a fully qualified name:

reg query "HKLM\SYSTEM\CurrentControlSet\Control\ComputerName\ComputerName" /v ComputerName
reg query "HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters" /v Hostname

(Microsoft's article queries ControlSet001; CurrentControlSet reads the active set.)

6. Rule out ordinary DC reachability

A secure channel failure caused by "can't reach any DC" has different evidence: DC locator errors rather than access denied. To confirm the server can locate a DC through DNS:

nltest /dsgetdc:contoso.com

This performs a DC locator lookup and contacts the DC it finds; it does not change the secure channel. If it fails, fix DNS, routing or the firewall first. The published DNS and site-to-site VPN articles cover those paths.

Interpreting the results

Decision guidance

Option A (preferred): reset the machine password from the member

Use this when AD is newer than the restored member and no duplicate is running.

# On the affected server, in an elevated Windows PowerShell 5.1 session,
# signed in with a local administrator (or cached domain) account.
$cred = Get-Credential   # an account allowed to reset this computer's password
Reset-ComputerMachinePassword -Server DC01 -Credential $cred

• -Server picks the DC to talk to. Choose one in the same site that is replicating normally; some administrators prefer the PDC emulator.
• -Credential is a domain account with rights to reset the password on this computer object. A Domain Admin works, but it is not required. Rights delegated for joining or resetting computers on the right OU are enough.
• The cmdlet returns no output on success. Verify with the steps below.
• Microsoft documents a remote form through Invoke-Command, but that only works if remote sign-in to the broken server still works. In this scenario it usually does not, so assume local or console access.

Alternative tools for the same change. Test-ComputerSecureChannel -Repair -Credential <cred> removes and rebuilds the channel. nltest /sc_reset:<domain> resets the channel, but does not change a mismatched password on its own. Pick one method and record which one you used.

Verification:

1. Test-ComputerSecureChannel returns True, and nltest /sc_query:<domain> shows NERR_Success and a DC name.
2. A domain user who has never signed in to this server can sign in (cached credentials do not prove the channel).
3. On a DC, the computer object's PasswordLastSet now shows today's time. Allow for replication before checking other DCs.
4. No new Netlogon 3210 events appear over the next scavenge cycles.
5. Services that run as domain accounts or as the computer account start and authenticate. Group Policy refreshes cleanly (gpresult /r shows a recent computer policy time).

Rollback: A password reset has no meaningful undo; the old value is replaced. If the reset was wrong (for example, the real problem was an older DC), the remedy is to fix the DC side and, if needed, reset again once it is healthy. Do not restore the member again to "undo".

Option B: reset the computer account in AD, then rejoin or reset from the client

Microsoft's Core Infrastructure blog lists Reset Account in Active Directory Users and Computers, followed by the client-side network ID process, as another route. It also notes that the account used does not need to be a Domain Admin, but does need rights to reset or join the computer object. This is a reasonable choice if PowerShell is unavailable. It takes more steps, and may need the restrictive ACLs on some existing computer objects corrected first.

Option C: leave and rejoin the domain

Microsoft calls rejoining a valid solution. Use it when the computer object is gone, or when Options A and B fail for permission reasons you cannot fix quickly. Before you do:

• Record the object's group memberships, its OU, and any delegation or SPNs on it (Get-ADComputer SERVER01 -Properties MemberOf, servicePrincipalName). Recreating the object loses them unless you re-add them.
• Do not delete the computer object if the same name is to be rejoined. Reuse it, so its identity and permissions survive.
• Plan for at least one reboot.

Restored domain controllers are a different procedure

If the machine you restored is a domain controller, stop. Its machine password, replication state and USN history must be handled with the DC-safe restore procedure. On a DC, netdom resetpwd /server:<other DC> /userd:<admin> /passwordd:* resets the DC's own secure channel password. Microsoft notes that it must be run on that DC and does not support member servers. See the published domain controller restore article before doing anything on a DC.

Make the next restore routine

Add these steps to the restore runbook for domain members:

1. Before powering on a restored member, make sure the original is off or isolated, so two machines never share the account.
2. After power-on, check nltest /sc_query:<domain> and the System log for Netlogon 3210 before declaring the restore complete.
3. If the channel is broken, perform the reset in Option A with a pre-approved delegated account, not a Domain Admin.
4. Confirm a fresh domain sign-in and service start before handing the server back.

What not to do

• Do not enable "Domain member: Disable machine account password changes" as a fix. Microsoft's default is Disabled and its guidance is not to enable it. The legitimate uses are narrow, such as non-persistent VDI pools and read-only embedded devices. Freezing the password weakens the channel used for pass-through authentication.
• Do not raise the maximum machine account password age to a very long value to "make restores easier". A longer interval gives an attacker longer to work on a captured password, and it does not address the restore itself.
• Do not run nltest /sc_verify or Test-ComputerSecureChannel -Repair as "tests". They repair when they find a fault, which changes state before you have finished collecting evidence.
• Do not delete and recreate the computer object as a first response. You lose its group memberships, delegations and SPNs.
• Do not reset a member's password while a duplicate is running. The two will keep breaking each other.
• Do not read or export the $MACHINE.ACC LSA secret to "compare" passwords. Dates and events give you the same decision without handling secrets.
• Do not restore a domain controller to fix one member server. If AD is newer than the member, the member is what needs the reset.

Limitations

• No lab test was run for this article. Commands and outputs are from Microsoft documentation, and example output text varies by version.
• The exact tolerance for how old a restore can be before the channel breaks depends on how many password changes have occurred and which DC answers. This article does not give a fixed number of days.
• The cmdlet references used here are the Windows PowerShell 5.1 pages. Run these steps in an elevated Windows PowerShell 5.1 session rather than assuming the cmdlets behave the same in PowerShell 7; that was not checked for this article.
• Microsoft's nltest reference is the archived Windows Server 2012 R2 page. The command still ships with current Windows, but check its built-in help (nltest /?) on your version.
• Microsoft's machine account password Q&A is a 2009 blog post republished in 2019. Its core behaviour (client-driven change, current and previous values, 30-day default) matches the current policy page, but specific older details in it should not be treated as current documentation.
• Microsoft Entra-joined and hybrid-joined devices have additional device identity states not covered here. This article covers on-premises AD domain membership only.
• Read-only domain controllers, multi-forest trusts and trust passwords between domains are out of scope.

Acceptance checklist

• [ ] Domain sign-in failure confirmed with "trust relationship" message; local or cached sign-in works
• [ ] Netlogon 3210 events read; DC named and first occurrence time noted
• [ ] nltest /sc_query result recorded (status code and DC name)
• [ ] Computer object Enabled, PasswordLastSet compared with the backup or snapshot time
• [ ] Duplicate name and IP ruled out; original machine off or isolated
• [ ] DC reachability (nltest /dsgetdc) confirmed
• [ ] Repair method chosen (A, B or C) and the delegated account named
• [ ] After the repair: secure channel test true, fresh domain sign-in works, AD PasswordLastSet updated, no new 3210 events
• [ ] Domain-account services and Group Policy confirmed working
• [ ] Restore runbook updated with the post-restore secure channel check

References

All accessed 2 November 2026.

• Microsoft Learn, "Broken trust relationship between a domain-joined device and its domain due to secure channel issues": symptoms, event 3210, nltest /sc_query access denied, the two scenarios, hostname registry keys, rejoin as a valid fix. https://learn.microsoft.com/en-us/troubleshoot/windows-server/windows-security/broken-trust-relationship-domain-joined-device-its-domain-secure-channel-issues
• Microsoft Learn, "Test-ComputerSecureChannel" (PowerShell 5.1): returns true or false, -Repair removes and rebuilds the channel, -Server, -Credential, member computers only. https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.management/test-computersecurechannel?view=powershell-5.1
• Microsoft Learn, "Reset-ComputerMachinePassword" (PowerShell 5.1): resets the local computer's account password, -Server, -Credential, remote use with Invoke-Command. https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.management/reset-computermachinepassword?view=powershell-5.1
• Microsoft Learn, "Domain member: Maximum machine account password age": default 30 days, range, security trade-off. https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/security-policy-settings/domain-member-maximum-machine-account-password-age
• Microsoft Learn, "Domain member: Disable machine account password changes": default disabled, guidance not to enable, valid uses, nltest /sc_change_pwd. https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/security-policy-settings/domain-member-disable-machine-account-password-changes
• Microsoft Learn (archived), "Nltest" (Windows Server 2012 R2): /sc_query, /sc_reset, /sc_verify, /sc_change_pwd, /dsgetdc. https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/cc731935(v=ws.11)
• Microsoft Learn, "netdom resetpwd": domain controller only, must be run on that DC. https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/netdom-resetpwd
• Microsoft Tech Community, Ask the Directory Services Team, "Machine Account Password Process" (2009, republished 2019): client-driven change, scavenge interval, current and previous values, System Restore effect. https://techcommunity.microsoft.com/blog/askds/machine-account-password-process/396027
• Microsoft Tech Community, Core Infrastructure and Security Blog, "Secure Channel/Expired Machine Account Password Concerns – Revisited" (2020): offline computers do not break, Reset Account and network ID route, non-Domain-Admin rights. https://techcommunity.microsoft.com/blog/coreinfrastructureandsecurityblog/secure-channelexpired-machine-account-password-concerns/1333535

Related articles

• Domain Controllers on VMware: Snapshots and Restores
• SQL Kerberos After Migration: Check SPNs and NTLM Use
• Group Policy Not Applying: gpresult, Events and SYSVOL
• Static IP Lost After a VM Restore or Virtual NIC Change

• DNS Changed but Users Still Reach the Old Application

• Duplicate IP or MAC Address After a VM Clone or Restore: Prove It, Contain It, Fix the Copy

• Account Keeps Locking Out: Find the Source From Event 4740 to the Process
• Windows LAPS: Deploy It Safely and Recover the Local Administrator After a Restore

Learning notes

1. The computer, not Active Directory, decides when its machine password changes (30 days by default), and it keeps the current and previous values.
2. A restore or snapshot revert that crosses password changes can leave the member with values AD no longer accepts: Netlogon 3210, ERROR_ACCESS_DENIED from nltest /sc_query (state at last use) and a failing current channel test.
3. Establish direction first: AD newer than the image, consistent across DCs, with a current failing channel test and no DC restore, points to resetting the member; the image newer than AD, or DCs that disagree, points to a DC or replication fault.
4. Reset-ComputerMachinePassword -Server -Credential, run locally with delegated rights, fixes it without a rejoin. /sc_verify and -Repair change state, so they are not tests.
5. Never "fix" this by disabling machine password changes; build the post-restore channel check into the runbook instead.