Powershell Fix Trust Relationship

Start with PowerShell: run Test-ComputerSecureChannel -Repair -Credential DOMAIN\Admin on the affected PC. If that fails, work through three checks, missing computer account, unreachable domain controller, or snapshot or restore mismatch. A broken trust can block domain logon, Group Policy, Kerberos, and remote management. This guide follows the failure path in order, so you fix the right cause without resetting blindly.

What the trust error means

The error means the workstation’s secure channel to the domain controller is broken. That channel links the workstation and the domain controller, and it fails when the computer password stored in Active Directory no longer matches the one on the PC. Start by signing in with a local administrator account on the affected machine so you can run repair commands even when domain sign-in fails.

Likely causes

Most often, the machine password and Active Directory are out of sync. Less often, the computer account was disabled or deleted in Active Directory, the domain controller cannot be reached, or a VM snapshot or system restore rolled the machine password back to an older value. Broken trust can also show Event 3210 from NETLOGON, and time sync problems may show Event 130 from Time-Service.

• Password mismatch between the workstation and Active Directory.
• Computer account missing or disabled in Active Directory.
• Domain controller or DNS reachability problem.
• Snapshot or restore rollback on a virtual machine or a restored system image.

How do I fix the trust relationship between this workstation and the primary domain failed with PowerShell?

Use PowerShell first. Run Test-ComputerSecureChannel to check the channel, then try -Repair with domain credentials if the check returns False. Microsoft introduced Test-ComputerSecureChannel in PowerShell 3.0, and it can check and repair the secure channel on domain-member computers. In some cases, it can repair the channel without a reboot.

1. Sign in with a local administrator account.
2. Open PowerShell as administrator.
3. Run Test-ComputerSecureChannel.
4. If it returns False, run Test-ComputerSecureChannel -Repair -Credential DOMAIN\Admin.
5. Run Test-ComputerSecureChannel again to verify the result.

Suppose a laptop is still on the network but domain logon fails after a password change. Local admin sign-in, followed by Test-ComputerSecureChannel -Repair, is the fastest path if the computer account still exists and the domain controller responds.

Is the secure channel broken?

Run Test-ComputerSecureChannel first. A True result means the secure channel is working; False means trust is broken and you need repair or another path. The cmdlet applies to domain-member computers only, so a workgroup PC is not a valid target for this check.

1. Open an elevated PowerShell prompt.
2. Run Test-ComputerSecureChannel.
3. If the result is True, stop here and look for another cause.
4. If the result is False, move to repair with credentials.

Repair the secure channel

Try Test-ComputerSecureChannel -Repair with domain credentials before you move to a full rejoin. Woshub documents the Repair mode with credentials, and this path often fixes a password mismatch without a reboot. If the command succeeds, validate it right away with a second Test-ComputerSecureChannel run.

1. Confirm you can sign in locally.
2. Open PowerShell as administrator.
3. Run Test-ComputerSecureChannel -Repair -Credential DOMAIN\Admin.
4. Run Test-ComputerSecureChannel again.
5. If the result is still False, move to machine password reset.

If -Repair throws a credential error, the account you used may not have rights to update the machine password, or the domain controller may be unreachable. Check the domain controller name, DNS resolution, and the network path before trying again.

Do you need to reset the machine password?

Use Reset-ComputerMachinePassword when secure channel repair fails but the domain controller is reachable. Woshub lists it as another PowerShell fix. It resets the computer account password, which is the value stored in Active Directory for the machine. That command still needs valid domain credentials.

1. Verify the domain controller resolves by name from the workstation.
2. Open PowerShell as administrator.
3. Run Reset-ComputerMachinePassword -Server DC01 -Credential DOMAIN\Admin.
4. Run Test-ComputerSecureChannel afterward.
5. If needed, repeat the command with a different reachable DC.

Picture a desktop that can log in locally, but cannot contact the DC because a VPN is down. In that case, the reset command will not help until the workstation can reach the domain controller over the network.

What if the computer account is missing?

Check the Active Directory computer account before you keep retrying repair. That account stores the machine password, and repair will not work if the account is missing or disabled. If the account was deleted, a repair command will not recreate it; a domain rejoin is usually the next step.

1. Open Active Directory Users and Computers.
2. Find the computer object for the affected workstation.
3. If the object exists but is disabled, enable it.
4. If the object is missing, plan a domain remove and rejoin.
5. After any change, retry Test-ComputerSecureChannel -Repair.

A common first-timer mistake is to keep running repair commands when the computer object was deleted a week earlier. If the object is gone, the fix is not another repair attempt; it is to recreate trust by rejoining the domain.

Powershell fix trust relationship decision table

What does Test-ComputerSecureChannel return when trust is broken?

When trust is broken, Test-ComputerSecureChannel returns False. A successful repair should produce True afterward. If you need a faster alternate check, the cmdlet can also be paired with -Repair and credentials, but a plain False means the secure channel still needs fixing.

Can I fix a broken domain trust without rebooting?

Yes, sometimes. Test-ComputerSecureChannel -Repair can repair the channel without rebooting, and LazyAdmin notes a PowerShell approach that avoids rebooting between unjoin and rejoin. Still, some cases need a restart after the account state changes, especially when services or cached tokens have not refreshed.

1. Run Test-ComputerSecureChannel -Repair -Credential DOMAIN\Admin.
2. If it succeeds, verify with Test-ComputerSecureChannel.
3. If domain logon still fails, sign out and sign back in.
4. Reboot only if the new trust state does not take effect.

Still not working?

If the secure channel still fails after repair and password reset, use NLTEST as another path. Run nltest /sc_verify:DOMAIN to check trust and nltest /sc_reset:DOMAIN to reset it. Then check DNS, routing, and DC reachability again. If the computer account is missing or the password state remains broken, remove the PC from the domain and rejoin it.

1. Run nltest /sc_verify:DOMAIN.
2. If that fails, run nltest /sc_reset:DOMAIN.
3. Recheck DNS resolution to the DC.
4. If trust still fails, unjoin and rejoin the domain.
5. Use a reboot only if the rejoin process or policy requires it.

A VM that was rolled back to a snapshot can look healthy locally while the domain password is stale. In that case, the cleanest fix is usually a password reset or a domain rejoin, not repeated sign-in attempts.

Prevention

For virtual machines, avoid reverting to older snapshots unless you expect to repair domain trust afterward. If you manage endpoint images, keep a record of restore points and domain lifecycle steps so rollback does not leave the machine with an outdated password.

Frequently asked questions

Do I need to rejoin the domain if Test-ComputerSecureChannel -Repair fails?

Not always. If the DC is reachable and the computer account still exists, try Reset-ComputerMachinePassword first. Rejoin the domain when the account is missing, deleted, or the secure channel still fails after a reset.

What causes a computer to lose trust with Active Directory?

The usual cause is a password mismatch between the workstation and the computer account in Active Directory. Snapshot rollback, system restore, account deletion, account disablement, and DC reachability problems can all lead to the same failure path.

Can the trust relationship issue happen after a VM snapshot or system restore?

Yes. A snapshot or restore can roll the machine password back to an older value, while Active Directory keeps the newer one. That mismatch breaks the secure channel, so the next step is usually repair, machine password reset, or a domain rejoin.