You boot up a Windows machine, try to log in using your domain credentials—and then get slammed with the dreaded message:
“The trust relationship between this workstation and the primary domain failed.”
This frustrating but common issue happens when a domain-joined computer can no longer securely communicate with the domain controller. It typically results from mismatched machine account passwords or system snapshots.
Fortunately, there are several reliable ways to fix this problem without removing and rejoining the domain—some of which can even be done remotely.
What Causes This Error?
When a Windows machine joins a domain, it establishes a secure channel with the domain controller, using a machine account password that changes every 30 days by default.
This error usually occurs when:
- A workstation’s password gets out of sync with the domain controller.
- A VM or system is restored from an old snapshot.
- There’s a domain controller rollback or replication lag.
- Network or AD-related configuration changes occur without rejoining.
Option 1: Fix Using PowerShell (No Domain Leave Required)
This is the cleanest and quickest fix—works only if you’re logged in with local admin privileges:
Reset-ComputerMachinePassword -Server "DomainControllerName" -Credential (Get-Credential)
- You’ll be prompted to enter domain credentials.
- The command resets the machine account trust relationship with the specified DC.
When it works:
- You’re logged in as local or cached domain admin.
- The workstation has network access to the DC.
Option 2: Use Netdom (Remote or CLI)
Netdom is part of RSAT tools and built into domain-joined systems.
netdom resetpwd /s:DomainControllerName /ud:DomainName\AdminUser /pd:*
s:specifies the domain controller.ud:is the user performing the reset.pd:*prompts for password securely.
Pros:
- Scriptable and fast.
- Great for use in login scripts or batch repair processes.
Option 3: Rejoin Domain (Non-Destructive)
If the above methods fail, rejoining the domain can help—without losing profile data.
Step 1: Change to Workgroup
- Go to System Properties > Computer Name tab
- Click Change…
- Select Workgroup, enter any name (e.g., WORKGROUP)
- Restart the PC
Step 2: Rejoin Domain
- Repeat steps above and this time select Domain
- Provide valid domain credentials
- Restart again to complete the trust rebuild
Tip:
- This method retains user profile data, but make sure to backup user data beforehand in case of login conflicts.
Option 4: Use Local Admin and RDP Backdoor (Remote Repair)
If you have remote access tools and cached credentials:
- RDP or use PSRemoting into the machine using a local admin
- Run the PowerShell or Netdom fix from above
- Restart the system
This is ideal in scenarios like:
- VDI environments
- Disaster recovery
- Systems with restricted physical access
Preventative Tips
| Action | Benefit |
|---|---|
| Don’t use old snapshots | Prevent machine password mismatch |
| Configure machines to sync passwords more often | Reduces trust issues in long-lived VMs |
| Use Group Policy to manage machine password behavior | Centralized control of trust policies |
| Monitor domain controller replication health | Avoid mismatched credentials between DCs |
| Consider monitoring for trust errors | Early detection of widespread domain trust issues |
Advanced: Disable Machine Password Changes (for Test Systems Only)
Warning: Not recommended in production.
Set-ItemProperty -Path "HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters" -Name "DisablePasswordChange" -Value 1 -Type DWORD
This prevents the machine from changing its password. Useful in lab environments or for persistent VMs with snapshot rollback.
Conclusion
A broken trust relationship between a workstation and a domain can be frustrating, but it’s not the end of the world. With tools like PowerShell and Netdom, you can often resolve the issue without fully removing the computer from the domain. Always aim for the least disruptive approach first—and remember to verify replication health and avoid snapshot pitfalls in domain-joined environments.
