How to fix “trust relationship between this workstation and the primary domain failed”

Introduction

The error “The trust relationship between this workstation and the primary domain failed” is one of the most common issues administrators encounter in Active Directory environments.

It usually appears when a domain-joined computer attempts to authenticate with a domain controller but the secure channel between the computer and the domain is broken. When this happens, the machine can no longer validate domain credentials and users are unable to log in using domain accounts.

This problem often occurs after:

  • restoring a virtual machine snapshot
  • resetting a computer account incorrectly
  • Active Directory replication problems
  • machine account password mismatch

The good news is that in most cases the issue can be resolved in less than a minute without removing the computer from the domain.

Quick fix

In many cases the fastest solution is to repair the secure channel using PowerShell.

Test-ComputerSecureChannel -Repair -Credential domain\admin

If PowerShell repair does not work, you can also reset the computer account password using:

netdom resetpwd /server:DC01 /userd:domain\admin /passwordd:*

Both commands re-establish the trust relationship between the computer and the domain controller.

What the error actually means

When a computer joins a domain, Active Directory creates a computer account for that machine.

This computer account works similarly to a user account. It has its own password, which is used to establish a secure communication channel between the workstation and the domain controller.

The authentication process looks roughly like this:

How the secure channel normally works

✔ Result: Secure channel established

The workstation authenticates using its machine account password. If the password matches the one stored in Active Directory, the secure channel is established.

What happens when the trust relationship breaks

✘ Result: Trust relationship between workstation and domain failed

The workstation still uses an old machine account password, but the domain controller expects a different password stored in Active Directory.

If the password stored on the computer does not match the password stored in Active Directory, authentication fails and the secure channel breaks.

When this happens, Windows shows the error:

The trust relationship between this workstation and the primary domain failed

Common causes of this problem

Virtual machine snapshot rollback

One of the most common causes is restoring a virtual machine snapshot.

When a VM snapshot is restored, the local machine account password stored on the computer may revert to an older value. Meanwhile, Active Directory still has the newer password.

This creates a mismatch.

Computer account password change

By default, domain-joined computers automatically change their machine account password every 30 days.

If something interrupts this process or a system is restored from backup, the stored password may no longer match the one in Active Directory.

Active Directory replication issues

If domain controllers are not replicating properly, a workstation might contact a DC that has outdated information about the computer account.

This can cause authentication failures.

Incorrect computer account reset

Sometimes administrators reset or recreate computer accounts manually in Active Directory.

If the workstation is not updated accordingly, the machine password may become invalid.

Solution 1 — Repair the secure channel using PowerShell

This is usually the best and fastest solution.

Open PowerShell as administrator and run:

Test-ComputerSecureChannel -Repair -Credential domain\admin

You will be prompted for domain credentials.

If successful, PowerShell returns:

True

This means the secure channel has been restored and the computer can authenticate with the domain again.

This method is preferred because:

  • it does not require leaving the domain
  • it does not affect user profiles
  • it can be automated through scripts

Solution 2 — Reset the computer account password using netdom

Another reliable method is the netdom command.

Run the following command from an elevated command prompt:

netdom resetpwd /server:DC01 /userd:domain\admin /passwordd:*

Explanation:

  • /server — domain controller to use
  • /userd — domain admin account
  • /passwordd — password prompt

After running the command, restart the computer.

This resets the machine account password and restores the secure channel.

Solution 3 — Remove and rejoin the computer to the domain

If other methods fail, you can rejoin the computer to the domain.

Steps:

  1. Log in using a local administrator account
  2. Open System Properties
  3. Change the computer from the domain to a workgroup
  4. Restart the machine
  5. Join the computer back to the domain
  6. Restart again

Although this works, it is usually not the best solution because:

  • it requires two reboots
  • some profiles or services may break
  • it takes more time

For this reason, repairing the secure channel is usually preferred.

Solution 4 — Reset the computer account in Active Directory

Another option is to reset the computer account directly in Active Directory Users and Computers.

Steps:

  1. Open Active Directory Users and Computers
  2. Locate the computer object
  3. Right-click the computer
  4. Select Reset Account

After resetting the account, restart the workstation and attempt to log in again.

Useful troubleshooting commands

Before repairing the secure channel, it can be helpful to verify domain connectivity.

Verify secure channel

nltest /sc_verify:domain.local

Check domain controller connectivity

nltest /dsgetdc:domain.local

Check DNS configuration

ipconfig /all

Incorrect DNS configuration is a common cause of domain authentication issues.

Best practices to avoid this issue

Although this error is common, a few best practices can reduce the likelihood of encountering it.

Avoid restoring domain-joined VMs from old snapshots

If snapshots must be used, ensure they are recent or consider resetting the secure channel after restoring.

Ensure proper Active Directory replication

Replication problems can cause authentication mismatches.

Verify correct DNS configuration

Domain-joined machines should use domain DNS servers only, not public DNS servers.

Monitor time synchronization

Kerberos authentication requires synchronized clocks.

Related guides

You may also find these topics useful:

  • How to check Active Directory replication status
  • How to reset a computer account in Active Directory
  • Common reasons Group Policy is not applying
  • How to check DNS resolution from PowerShell

References

Microsoft documentation for the commands mentioned in this guide:

Summary

The “trust relationship between this workstation and the primary domain failed” error occurs when the secure channel between a workstation and the domain controller breaks due to a machine account password mismatch.

In most cases the fastest solution is:

Test-ComputerSecureChannel -Repair

Alternative methods include resetting the computer password with netdom or rejoining the machine to the domain.

Understanding how the machine account and secure channel work helps administrators resolve this issue quickly and avoid unnecessary domain re-joins.