Fix Trust Relationship Between Workstation and Domain Failed Error

Yesterday your PC signed you in without a thought. This morning you type the same password you always use, and Windows refuses you with a flat statement: the trust relationship between this workstation and the primary domain failed. Your password is fine. What broke is the private handshake between your computer and your company’s domain controller, the secret the two of them share so the domain knows your PC is really yours. This only happens on domain-joined PCs, never on home computers, and the fixes below are ordered from fastest to last resort.

First, a Quick Check Before You Repair Anything

The “trust” in this error is literally a password your computer and the domain controller agree on, renewed automatically every 30 days. If something interrupted that renewal, a system restore rolled your PC back, the computer account was deleted in Active Directory, or the clock drifted, the two sides stop recognizing each other. Two minutes of diagnosis can save you a pointless rejoin:

  • Make sure the PC can actually reach the office network or VPN. No network, no domain, no login.
  • Check the date and time. A clock off by more than about five minutes causes Kerberos failures that look exactly like trust failures.
  • Ask your IT admin whether the computer account still exists in Active Directory. If it was deleted or disabled, the PowerShell repairs below will fail and you need a rejoin.
Diagram of the trust relationship between a Windows workstation and a domain controller showing the broken secure channel and machine account password
The secure channel between your PC and the domain controller depends on a shared machine account password. When they disagree, you get this error.

Fix 1: Repair the Secure Channel with PowerShell

This is the fastest fix and works whenever the computer account is still healthy in Active Directory. Log on to the affected PC with a local administrator account, since domain accounts are locked out.

  1. Open PowerShell as administrator (right-click Start, choose Terminal (Admin) or Windows PowerShell (Admin)).
  2. Check the state of the channel first:
    Test-ComputerSecureChannel -Verbose
    If it returns False, the channel is broken.
  3. Repair it:
    Test-ComputerSecureChannel -Repair -Credential (Get-Credential)
    Enter domain administrator credentials when the prompt appears.
  4. Run Test-ComputerSecureChannel -Verbose again. It should now report that the secure channel is in good condition. Restart the PC and sign in with your domain account.
See also  Fix Remote Computer Requires Network Level Authentication (NLA) Error: Quick Solution Guide

If the PC cannot reach the domain controller at all, you may see RPC-style connectivity errors. Troubleshooting the RPC server unavailable error covers the network side of that.

Fix 2: Reset the Machine Account Password Directly

If the channel repair returns an error instead of fixing things, force the workstation to push a brand-new machine account password to the domain. This works without testing the existing channel first.

  1. Open PowerShell as administrator and run:
    $credential = Get-Credential
    Reset-ComputerMachinePassword -Credential $credential
    Restart-Computer -Force
  2. Enter domain administrator credentials when prompted.
  3. The PC restarts with a fresh machine password synced to Active Directory. Log in with your domain account.
Illustration of the PowerShell Reset-ComputerMachinePassword command repairing the domain trust relationship
Reset-ComputerMachinePassword forces the workstation to push a new machine account password to Active Directory.

Fix 3: Remove and Rejoin the Domain

When the computer account is missing, disabled, or the repairs above fail, the classic disjoin-and-rejoin still works. It creates a fresh computer account in Active Directory.

  1. Log on as a local administrator. Press Windows key + R, type sysdm.cpl, and press Enter.
  2. On the Computer Name tab, click Change. Select Workgroup, type any name (such as WORKGROUP), and click OK. Enter administrator credentials when asked.
  3. Restart the PC. Log on as local administrator again.
  4. Open sysdm.cpl again, click Change, select Domain, type your domain name, and click OK. Enter domain administrator credentials.
  5. Restart once more and sign in with your domain account.

After rejoining, if you are blocked at a different login screen error, the user profile service failed sign-in guide covers the next most common failure.

Fix 4: Check Time Sync and Network Path to the Domain Controller

Kerberos authentication tolerates about five minutes of clock skew. If the PC’s clock is wrong, every domain login fails with symptoms identical to a trust failure. Also confirm DNS resolves your domain: a PC that cannot find its domain controller will never rebuild trust.

  1. Log on as local administrator and check the clock against a reliable source. Enable automatic time in Settings > Time & language > Date & time.
  2. From an elevated command prompt, run nltest /dsgetdc:yourdomain (replace yourdomain with your domain name) to confirm the PC can locate a domain controller.
  3. If you are remote, connect the VPN before attempting any domain login, then retry the PowerShell repairs.
See also  Fix "Hyper-V Hypervisor Is Not Running" Error in Windows: Complete Troubleshooting Guide

Microsoft’s own Q&A thread on this exact error walks through the same netdom and PowerShell repairs if you want a second reference.

Our Take: Repair First, Rejoin Only When the Account Is Gone

The PowerShell channel repair fixes the majority of these cases in under five minutes, and it preserves the computer’s existing identity in Active Directory. Reserve the disjoin-and-rejoin for when an admin confirms the computer account was deleted or disabled, because rejoining creates a new account and can disturb group policies and profiles tied to the old one. If this error keeps returning on the same machine, something deeper is wrong, a failing disk corrupting the local secret, a dying CMOS battery throwing the clock off, or a system-restore habit, and that is worth one proper investigation rather than a monthly repair.

Lokesh Sharma
Scroll to Top