The Trust Relationship Between This Workstation and the Primary Domain Failed: How to Fix It

“The trust relationship between this workstation and the primary domain failed” appears when you try to sign in to a domain-joined Windows PC or server with a domain account. It means the computer can no longer set up a secure channel with a domain controller, because the machine account password on the PC doesn’t match the one in Active Directory. The quickest fix is to sign in with a local administrator account and run Test-ComputerSecureChannel -Repair in Windows PowerShell, then restart.

The steps below apply to Windows 10, Windows 11 and Windows Server member servers. Domain controllers use a different command, covered at the end of the fixes.

What causes the trust relationship to fail

Every domain-joined computer has an account and password in Active Directory. By default, the computer changes that password every 30 days. If the PC and the domain end up with different passwords, the secure channel breaks. Microsoft lists these common reasons:

• Reverting a virtual machine to an old snapshot. The VM goes back to a machine password that Active Directory has since replaced.
• Restoring from an old bare-metal backup or System Restore point. Same problem: the PC gets an older password back.
• An unexpected shutdown right after a password change. On some devices the change is lost if the PC loses power.
• Two installations sharing one computer account, such as a dual-boot PC with both systems joined under the same name. Microsoft recommends giving each installation its own computer name.
• Non-persistent VDI images that reset to a base image at sign-out.

How to fix the trust relationship error

Fix	Command	Use it when
1. Repair the secure channel	Test-ComputerSecureChannel -Repair	First try on a workstation or member server
2. Reset the machine password	Reset-ComputerMachinePassword	The repair doesn’t work
3. Reset from Command Prompt	nltest /sc_reset, netdom reset	You prefer Command Prompt or have RSAT installed
Domain controller only	netdom resetpwd	The affected machine is a domain controller
4. Remove and rejoin	Remove-Computer, then Add-Computer	Fixes 1 to 3 fail; most disruptive option

Before you start

1. Sign in with a local administrator account. Domain sign-in won’t work until the trust is fixed, so use a local admin account on the PC (for example .\Administrator or PCNAME\localadmin).
2. Get domain credentials ready. You need an account allowed to reset the computer’s password in the domain, typically a domain admin.
3. Check that the PC can reach a domain controller. In PowerShell, run:

Test-Connection dc01.contoso.com

Replace dc01.contoso.com with the full name of one of your domain controllers. If there are no replies, fix the network or DNS problem first. None of the fixes below work without a connection to a domain controller.

Important: The commands in this guide need an elevated Windows PowerShell window (right-click Windows PowerShell and select Run as administrator). Test-ComputerSecureChannel, Reset-ComputerMachinePassword, Add-Computer and Remove-Computer are not available in PowerShell 7, so use the built-in Windows PowerShell 5.1.

Fix 1: Test and repair the secure channel

1. Open Windows PowerShell as administrator.
2. Check the secure channel:

Test-ComputerSecureChannel -Verbose

It returns True if the channel works and False if it’s broken.

3. If it returns False, repair it with domain credentials:

Test-ComputerSecureChannel -Repair -Credential CONTOSO\Admin01

Replace CONTOSO\Admin01 with your domain and admin account. You’ll be prompted for the password. The -Repair switch removes and rebuilds the secure channel that the NetLogon service maintains.

4. Restart the computer and sign in with your domain account.

Fix 2: Reset the machine account password

If the repair doesn’t work, reset the computer’s password directly.

1. In Windows PowerShell as administrator, run:

Reset-ComputerMachinePassword -Server "DC01" -Credential CONTOSO\Admin01

This sets a new computer account password using the domain controller DC01. Replace the server and account with your own. You can leave out -Server and Windows picks a domain controller for you.

2. Run Test-ComputerSecureChannel again. If it returns True, restart and sign in with your domain account.

Fix 3: Reset the secure channel from Command Prompt

If you prefer Command Prompt, Microsoft documents nltest for this.

1. Open Command Prompt as administrator, using an account with domain admin rights.
2. Run:

nltest /sc_reset:contoso.com

Replace contoso.com with your domain name. This resets the secure channel to the domain.

3. Restart the computer.

On machines that have the Active Directory Domain Services tools (RSAT) installed, netdom can do the same job:

netdom reset PC042 /domain:contoso.com /usero:CONTOSO\Admin01 /passwordo:*

Replace PC042 with the computer name. The * makes netdom prompt for the password instead of showing it on screen.

On a domain controller: don’t use Test-ComputerSecureChannel, because Microsoft says it returns false errors on domain controllers. Use netdom resetpwd on the affected domain controller instead:

netdom resetpwd /server:DC02 /userd:CONTOSO\Admin01 /passwordd:*

Here DC02 is the domain controller the command uses to set the password. netdom resetpwd only works on domain controllers, not member servers or workstations.

Fix 4: Remove the computer from the domain and rejoin it

Rejoining sets up the computer’s domain membership from scratch, but it’s the most disruptive option. Use it when Fixes 1 to 3 fail.

Important: Before you remove the PC from the domain, make sure you know the password of a local administrator account. After the unjoin, domain accounts can’t sign in until the PC rejoins. Remove-Computer also disables the computer’s account in the domain.

1. Remove the PC from the domain (it moves to a workgroup and restarts):

Remove-Computer -UnjoinDomainCredential CONTOSO\Admin01 -WorkgroupName "WORKGROUP" -Restart

2. Sign in with the local administrator account.
3. Open Windows PowerShell as administrator and rejoin the domain:

Add-Computer -DomainName "contoso.com" -Credential CONTOSO\Admin01 -Restart

4. After the restart, sign in with your domain account.

How to stop it from happening again

• Don’t revert domain-joined VMs to old snapshots unless you’re ready to repair the trust afterwards. The older the snapshot, the more likely the machine password has changed since. If a lab VM won’t even open, see our fix for VMware Workstation cannot connect to the virtual machine.
• Give dual-boot or cloned installations unique computer names so they don’t share one account.
• Don’t disable machine password changes as a workaround. Microsoft recommends leaving Domain member: Disable machine account password changes set to Disabled, because a password that never changes gives attackers more time to guess it. For non-persistent VDI, Microsoft suggests scheduling password changes in maintenance windows with Nltest /sc_change_pwd:<domain name>.

If it still doesn’t work

• Look for time jumps in Event Viewer. Microsoft suggests checking the System log for gaps of weeks or months, which point to a restored snapshot or backup.
• Check DNS on the PC. It must use your domain’s DNS servers to find a domain controller.
• Check the computer account in Active Directory. Make sure it exists, isn’t disabled, and isn’t shared with another PC of the same name.
• Citrix users with a different error. If people sign in fine but a published app won’t launch, that’s a separate problem: see Citrix Workspace cannot start app.
• Escalate. If several PCs lose trust at once, the problem may be on the domain controllers or replication. That needs your Active Directory admin. For other Windows problems, see our computer repair tips, and for opening an admin prompt quickly, see the elevated command prompt guide. More fixes are in PC Repairs.