Trust Relationship Failed on a Domain PC: How to Fix It

The full message reads The trust relationship between this workstation and the primary domain failed. You’ll only see it on a PC joined to an on-premises Active Directory domain, which in a small office usually means one Windows Server acting as the domain controller.

The error is about the computer, not you. Every domain PC has its own account in Active Directory, with a password the PC changes by itself, every 30 days by default. When the copy on the PC and the copy on the server stop matching, the server refuses every domain sign-in from that PC. Your own password still works, and your files are still on the disk.

The fix is to get into the PC another way, then reset that computer password with an admin account; rejoining the domain is the last resort.

Which cause do you have?

Match what happened just before the error to the most likely cause.

If nobody knows what changed, look in two places. On the PC, once you’re signed in (Step 1), Event Viewer > Windows Logs > System may show NETLOGON event 3210, naming the two usual reasons: a duplicate computer name or a computer password the server doesn’t recognize. On the server, in Active Directory Users and Computers, a missing PC was deleted and a down-arrow on its icon means it’s disabled.

Step 1: Sign in without the domain

Nothing can be repaired until you’re signed in to the PC with an account in its local Administrators group. There are two ways in.

A local administrator account

On the sign-in screen choose Other user and type the local account’s name with .\ in front, for example .\officeadmin. The prefix tells Windows to check the account on the PC itself. Windows 11 and Windows 10 keep the built-in Administrator account disabled by default, so this only works if someone created a local admin account.

If your office uses Windows LAPS backed up to Active Directory, a Domain Admin can read the PC’s local admin password on the server or an admin PC with Get-LapsADPassword -Identity PCNAME -AsPlainText, then sign in with .\ plus the name on the Account line. After an image or snapshot restore, the PC may still have an older password; -IncludeHistory lists older ones if LAPS password encryption is on. If LAPS backs up to Microsoft Entra ID instead, the password is on the device’s page in the Microsoft Entra admin center or Intune.

Your domain account, offline

Windows caches recent domain sign-ins, the last 10 users by default. If the PC can’t reach a domain controller, it checks that cached copy instead, and the failing trust check never runs.

1. At the sign-in screen, unplug the network cable, or disconnect Wi-Fi from the network icon in the corner.
2. Sign in with a domain account that has signed in to this PC before. To do the repair it must be a local administrator; members of Domain Admins are, because Windows adds that group to the PC’s Administrators group when it joins a domain. If that’s a Domain Admin, sign out after the repair so its powerful credentials don’t linger in the PC’s memory.
3. At the desktop, reconnect the cable or Wi-Fi. Don’t sign out yet, because the next domain sign-in fails again until the repair is done.

If neither way works, don’t reset Windows to get in: a reset removes apps and settings and doesn’t fix the computer account on the server.

Step 2: Repair the secure channel in PowerShell

The secure channel is the authenticated link the PC’s Netlogon service keeps with a domain controller. Rebuilding it puts a new computer password in place on both sides without leaving the domain.

1. Open Start, type Windows PowerShell and choose Run as administrator. It has to be Windows PowerShell 5.1, built into Windows; PowerShell 7 doesn’t include these cmdlets.
2. On the office network or VPN, test the channel: Test-ComputerSecureChannel -Verbose. False means the trust is broken, provided a domain controller is reachable; off the network, the test and the repair both fail. True means the trust is fine and the problem lies elsewhere, often DNS or the clock.
3. Repair it with a domain account that’s allowed to reset computer accounts, usually a Domain Admin: Test-ComputerSecureChannel -Repair -Credential YOURDOMAIN\adminname. Windows prompts for that account’s password.
4. Run the test again. When it returns True, sign out and sign in normally with your domain account. Restart if mapped drives or policies still misbehave.

If the repair fails, reset the computer password against a named domain controller, replacing DC01: Reset-ComputerMachinePassword -Server DC01 -Credential YOURDOMAIN\adminname. That helps when an office has two domain controllers and the PC keeps picking the unhealthy one.

Two checks before you try again. The PC’s clock and the server’s must be no more than five minutes apart, the default limit for Kerberos, which domain sign-in relies on; a wrong time zone with a local time that looks right means the clock is really hours off. And a PC joined to an Active Directory domain must use only your domain controllers for DNS: never the router, your internet provider or a public service such as Google or Cloudflare, not even as the alternate server. Otherwise it can’t find the domain.

Step 3, last resort: leave and rejoin the domain

Before you start: confirm a local administrator account signs in, because once the PC leaves the domain, no domain account can sign in until it rejoins. Don’t delete the PC’s computer object in Active Directory to start fresh: BitLocker recovery keys backed up to Active Directory and any Windows LAPS password live on that object and disappear with it. Copy the recovery key somewhere safe first; here’s where to find a BitLocker recovery key.

1. Sign in with the local admin account. Press Windows key + R, type sysdm.cpl, and on the Computer Name tab select Change.
2. Under Member of, choose Workgroup, type WORKGROUP, select OK and restart when asked.
3. Sign in with the local admin account again, open the same dialog, choose Domain, type your domain name and enter a domain admin account when prompted. Restart.

In Windows PowerShell 5.1 opened as administrator (PowerShell 7 dropped these cmdlets too), the equivalents are Remove-Computer -UnjoinDomainCredential YOURDOMAIN\adminname -WorkgroupName WORKGROUP -Restart, then Add-Computer -DomainName yourdomain.local -Credential YOURDOMAIN\adminname -Restart. Removing a PC disables its computer account, and joining again under the same name reuses that account.

If the join fails with An account with the same name exists in Active Directory. Re-using the account was blocked by security policy, you’ve hit the domain join hardening Microsoft began rolling out in October 2022. Windows reuses the existing computer object only if you join with the account that created it, or if a member of Domain Admins, Enterprise Admins or the built-in Administrators group created it; joining as a Domain Admin isn’t enough by itself. Retry with the account that originally joined this PC, rename the PC and join it as a new computer, or have an admin list trusted account creators in the Domain controller: Allow computer account re-use during domain join policy.

What happens to your profile

Rejoining the same domain keeps your desktop, files and Outlook setup, because Windows finds your profile by your user account’s security ID (SID), which doesn’t change unless the account is deleted and recreated. If Windows hands you a temporary profile instead, follow User Profile Service failed the sign-in. A Windows Hello for Business PIN often needs setting up again after a rejoin; see how to fix a PIN that isn’t available.

Several PCs at once? Check the old server first

When two or more PCs lose trust on the same day, the server changed, not the PCs. Usually it’s one of these:

• The domain controller was restored from an old backup, a disk image or a virtual machine snapshot. Active Directory then holds older computer passwords than the PCs, and an unsupported restore can damage Active Directory itself, so don’t restore it again before someone has checked it.
• A second domain controller stopped replicating, so a PC that changed its password on one server is rejected by the other. In Command Prompt opened as administrator on a server, dcdiag reports health and repadmin /replsummary shows replication failures.
• The server’s clock is wrong. Check its date, time and time zone.

While you’re at the server, run winver. Windows Server 2016’s end of support date is January 12, 2027, and paid security updates for 2012 R2 ended in October 2026; a server every sign-in depends on shouldn’t be out of support.

Many small offices no longer need a server for sign-ins: PCs can be Microsoft Entra joined and managed with Intune, which is included in Microsoft 365 Business Premium or licensed separately, with shared files in SharePoint or OneDrive. That’s a planned project, and apps or file shares that depend on the server need a plan first. For how licensing and SharePoint fit together, see our Microsoft 365 management page.

Microsoft Entra joined and hybrid joined PCs

Run dsregcmd /status in Terminal (or Command Prompt) and read the first section:

If work sign-ins fail on a PC that’s only Entra joined, an admin should check in the Microsoft Entra admin center, under Entra ID > Devices > All devices, whether the PC was disabled. Don’t delete the device record: Microsoft notes that deletion can’t be undone and removes BitLocker keys stored with it.

When to stop and get help

• Neither a local admin account nor a cached domain sign-in works on the PC.
• Several PCs fail at once, or nobody knows the domain admin password for the server.
• The server was recently restored from a backup or snapshot.
• The PC asks for a BitLocker recovery key that nobody can find.
• The same PC loses trust again within weeks.

If one PC is affected, you can get signed in with a local or cached account, and someone in the office knows the domain admin password, this is a typical $59 remote fix: with your permission, a technician connects and works through the repair and the likely cause while you watch, and you can end the session at any time. Have the person who knows that password type it in when Windows asks, rather than sending it by email or chat. Repairing the server itself, or moving the office off it, is planned work.

Common questions

Will rejoining the domain delete my files or profile?

No. Leaving and rejoining a domain doesn’t touch the files on the PC, and your domain user account keeps the same security ID, so Windows loads your existing profile when you sign in again. What can change is anything tied to the computer account: its group memberships, policies aimed at that PC, and BitLocker keys stored in Active Directory if someone deleted the old computer object. Make sure a local admin account works before you start.

Can a trust relationship failure be fixed remotely?

Often, yes. Once someone at the PC signs in with a local administrator or cached domain account, a technician can connect with a remote support tool and run the repair, as long as the PC can reach a domain controller, in the office or over a VPN, and someone can enter the domain admin password. Remote Desktop and PowerShell remoting with a domain account don’t work beforehand, because the PC can’t verify domain accounts until its trust is repaired.

Why does the trust relationship keep failing on the same PC?

A repeat failure means something keeps undoing the repair. The usual suspects are two machines using the same computer name, each resetting the one account they share; a virtual machine that keeps being rolled back to a snapshot; a PC restored from the same old image; or a cleanup script that disables idle computer accounts. Look for duplicate names in Active Directory and rename one PC before rejoining it.

How do I stop a virtual machine losing trust after restoring a snapshot?

A snapshot keeps the computer password the VM had when it was taken. If the VM changed that password afterward, every 30 days by default, reverting can put back one the domain no longer accepts. Run Test-ComputerSecureChannel -Repair after the revert, then take a fresh snapshot so later reverts start from the current password. Microsoft advises against turning off machine password changes except in special cases such as non-persistent virtual desktops, so don’t use that workaround on office PCs or servers.

Can I fix the trust relationship without a domain admin password?

Not completely. Signing in offline with cached credentials gets you to the desktop, but resetting the computer password needs a domain account that’s allowed to reset computer accounts, normally a Domain Admin, plus local admin rights on the PC. In a small office where nobody knows the server’s admin password, recovering that access is the real problem, and it has to be solved at the server.

Why does PowerShell say Test-ComputerSecureChannel is not recognized?

You’re probably in PowerShell 7, which Windows Terminal can open by default once it’s installed. Microsoft dropped Test-ComputerSecureChannel and Reset-ComputerMachinePassword from PowerShell 7, so open Windows PowerShell, the 5.1 version included with Windows, using Run as administrator. The cmdlets also only work on domain member PCs; for a domain controller’s own channel, Microsoft points to netdom or nltest.

How long can a domain computer stay offline before it loses trust?

There’s no built-in limit. A domain PC changes its own computer password, every 30 days by default, and one that has been switched off for months simply changes it the next time it connects. Trust breaks only if something else happened in the meantime, such as an admin or a script disabling or deleting idle computer accounts, or the PC being restored from an older image.