Trust Relationship Broken – Fix Without Domain Rejoin

You see "The trust relationship between this workstation and the primary domain failed" when you try to log in. This happens more often than you'd think — usually after a system restore, a VM clone, or a password mismatch that happens silently.

What's actually happening here is that your computer's machine account password (stored locally) doesn't match the one stored in Active Directory. Every 30 days, Windows rotates this password automatically. If that rotation fails — say, because the computer was offline for a long time, or because you restored an old system state — the passwords go out of sync. The domain controller then refuses the connection.

The fix is to reset that machine account password. You have two good ways to do it: PowerShell (simpler, works on Win10/11 and Server 2016+) or netdom (older tool, still works on Server 2012 R2). I'll cover both below.

Cause 1: Machine Account Password Mismatch – Fix with PowerShell

This is the most common cause. The computer account password in AD and the local copy don't match. The fastest fix is a single PowerShell cmdlet that forces a secure channel reset.

Prerequisites: You need a local administrator account that can still log in. If you can't log in at all, you'll need to use Safe Mode with Networking or the built-in Administrator account (if enabled).

1. Open PowerShell as Administrator. Right-click Start, choose Windows Terminal (Admin) or PowerShell (Admin).
2. Run this command:

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

You'll be prompted for domain admin credentials. Enter them. The cmdlet checks the secure channel and repairs it if broken.

What's happening behind the scenes: Test-ComputerSecureChannel does two things. First, it contacts a domain controller and tries to authenticate using the current machine account password. If that fails, it sends a secure channel reset request, which tells the DC to update its copy of the password to match the local one. The -Repair switch automates the second step.

If the command succeeds, you'll see True. Try logging in with a domain account. If it still fails, reboot and try again.

Why this might not work: The machine account might be disabled or deleted in AD. In that case, you get False. Then you need to rejoin the domain (see Cause 3 below).

Cause 2: System Restore or VM Snapshot Rollback – Fix with netdom

This is common on virtual machines. You take a snapshot, run the VM for weeks, then revert to that old snapshot. The machine account password in the snapshot is old. The DC has a newer one. Boom — trust broken.

Same fix as above, but some people prefer the older netdom tool because it gives you more verbose output. netdom is included with Windows Server and can be added to Windows 10/11 via RSAT.

If you have netdom installed:

1. Open Command Prompt as Administrator.
2. Run:

netdom resetpwd /server:<DCName> /userd:<Domain>\<AdminUser> /passwordd:*

Replace <DCName> with any domain controller (use one that's responding), <Domain>\<AdminUser> with a domain admin. You'll be prompted for the password.

What netdom resetpwd actually does: It updates the machine account password locally and on the DC in one secure operation. The /server: flag tells it which DC to talk to. The password is encrypted during transit — not sent as plaintext.

After it completes, reboot. That's it.

If you don't have netdom, stick with the PowerShell fix from Cause 1. It does the same thing — just less verbose.

Cause 3: Machine Account Deleted or Disabled in AD – Rejoin Required

Less common, but happens when an admin accidentally deletes the computer object in Active Directory Users and Computers. Or the computer is disabled after too many failed logins. In either case, no amount of password reset will help — the account doesn't exist or can't authenticate.

Quick check: On a domain controller, open AD Users and Computers, find the computer object. Right-click it, choose Properties. Check the Account tab. If it's disabled, enable it. If it's gone, you need to rejoin.

To rejoin the domain:

1. Log in with a local admin account.
2. Open System Properties (sysdm.cpl).
3. Under Computer Name, click Change.
4. Select Workgroup, give it a name like WORKGROUP, click OK. Reboot.
5. Log back in as local admin. Go back to System Properties, select Domain, enter the domain name, provide admin credentials. Reboot again.

Why the extra reboot? The local machine account password is stored in the SAM registry hive. When you leave the domain, Windows generates a new local account. When you rejoin, it creates a fresh machine account in AD. The reboots flush any cached credentials and force the new trust to establish cleanly.

Pro tip: Before rejoining, have someone check if the old computer object exists in AD. If it does but is disabled, just enable it and use the PowerShell fix from Cause 1 — no rejoin needed. If it's deleted or corrupted, rejoin is the only clean option.

Quick-Reference Summary

One last thing: if you're cloning VMs in VMware or Hyper-V, always sysprep before cloning. Sysprep generates a new machine SID and password, which prevents this exact trust break.