The Security Database on the Server Does Not Have a Computer Account for This Workstation Trust Relationship: 7 Fixes Ranked by Risk

That error means the computer's machine-account password no longer matches the copy stored in Active Directory, so the domain controller refuses the logon. The condition is a broken secure channel between one workstation and its domain. Either the workstation's password changed without the domain hearing about it, or the account itself was removed, disabled, or duplicated. Fixing it means rebuilding that trust — and the safest order of repairs runs from a simple rejoin to a full account reset, because each step further up the ladder touches more than one machine.

The message usually arrives as a Windows logon failure: "The trust relationship between this workstation and the primary domain failed." The full wording about the security database appears in event logs and in the Netlogon error family. Both phrases describe the same broken secure channel.

Here is the part most write-ups skip: a failed trust does not always mean a broken password. On Windows 10 and 11, Fast Startup can restore a stale machine-password cache after shutdown, which produces this exact error on a machine that was working the day before. Check that first if the failure appeared overnight with no password or account changes. It takes two minutes and saves a domain rejoin.

One boundary before you start: everything below assumes you have local administrator access to the affected machine and a domain account with rights to reset or rejoin computer objects (Domain Admin, or delegated rights on the computer's OU). Without those two things, stop and get help from whoever holds them. Resetting a machine account is not a self-service operation, and doing it wrong on a shared machine can strand other users.

A second boundary worth stating early: this is an Active Directory problem, not a Windows problem. The server in the error message is the domain controller, and the security database is NTDS.dit on that controller. Nothing you do inside Windows alone repairs the server side; you are always either resynchronizing the client's cached password or rewriting the server's record.

Why the Secure Channel Breaks and What the Event Log Tells You

A domain-joined Windows machine keeps a computer account password, rotated automatically every 30 days by default. The client stores its half locally; the domain controller stores the other half in Active Directory. A broken trust is simply those two halves disagreeing, and the event log names which side is wrong often enough to short-circuit diagnosis.

The default rotation interval is controlled by the MaximumPasswordAge value on the computer object, which defaults to 30 days. A machine that has been offline longer than that — a laptop on a long leave, a VM restored from an old snapshot, a factory-floor PC powered down for months — will come back with a password the domain has already replaced. That is the single most common organic cause.

Event ID 3210 in the System log (source Netlogon) reports that the machine failed to authenticate with the domain. On the domain controller side, look for Netlogon event 5722, which names the computer account that failed to authenticate, and 5723, which records an unexpected authentication failure for a computer account. If 5722 and 5723 fire together within seconds, the secure channel is broken and the account still exists — a rejoin or reset fixes it. If you see no 5722 at all but the client still fails, suspect the account was deleted outright.

Three causes account for nearly every case in practice. First, the machine was offline past the 30-day rotation window. Second, someone restored a domain controller or a client from backup, and the restored password predates the current one. Third, the computer object was deleted and recreated — by a reimaging script, a duplicate-name cleanup, or an admin removing a stale object — leaving the client holding credentials for an account that no longer matches.

A fourth cause is the one to rule out before anything else: Fast Startup. Windows 10 and 11 hybrid shutdown saves the kernel session to hiberfil.sys, and a machine that was shut down rather than restarted can resume with a cached machine password that the domain has since rotated. Turning off Fast Startup (Control Panel, Power Options, Choose what the power buttons do, uncheck Turn on fast startup) and performing a full restart clears the cached state.

Before You Rejoin: The Local Account Escape Hatch

If you cannot log on at all, the first move is to get a session, not to fix the trust. A local administrator account — created before the machine joined the domain, or enabled afterward — logs on without contacting a domain controller, and that session is where every repair below happens.

Windows caches up to 10 previous domain logons by default (CachedLogonsCount under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon). If the last successful domain logon is still cached and the password has not changed since, you may be able to log on with domain credentials while disconnected from the network. That gets you a desktop for the tools, though the trust itself stays broken until you act.

For a machine with no working local admin credential, the recovery path is the built-in Administrator account, enabled from Windows Recovery Environment or via a bootable media session. That is a last resort with its own risks on BitLocker-encrypted disks — have the recovery key ready before you boot to WinRE, because recovery mode can trigger a BitLocker recovery prompt on some configurations.

Once you have a session, run whoami /user from an elevated command prompt. If it returns a local machine SID rather than a domain SID, you are logged on locally and can proceed. Note the computer name with hostname and confirm the domain with echo %USERDOMAIN% — you will need both for the rejoin, and typos in the domain name are a common cause of a rejoin that appears to succeed and fails at the next reboot.

The Four-Line PowerShell Fix and How It Differs From a GUI Rejoin

Test-ComputerSecureChannel is the supported way to test and repair the channel from the client side. Run PowerShell as administrator, and run Test-ComputerSecureChannel -Verbose first — it returns True or False and prints whether the channel is valid. If it returns False, Test-ComputerSecureChannel -Repair -Credential (Get-Credential) prompts for a domain account with rights on the computer object and resets the local machine password to match the domain's copy.

The -Repair switch works by resynchronizing the local machine password with the domain, not by rewriting the domain's copy. That distinction matters: if the domain account was deleted, -Repair fails with an error rather than recreating the object. It fixes the most common cause — a stale local password — and leaves the domain side untouched.

The GUI route is System Properties, Computer Name tab, Change, then either re-entering the domain or removing the machine from the domain and rejoining. That path recreates the computer object's secure channel on the domain side and is more disruptive: the machine leaves the domain and rejoins, and any Group Policy that applies at join time runs again. Both routes require a reboot to take effect, and neither works if the account is disabled in Active Directory.

One detail the quick guides miss: Test-ComputerSecureChannel -Repair uses the credential you supply to reset the machine password, and on a machine with a stale Group Policy cache the repair can fail with a "the specified account already exists" error if the domain account is intact but disabled. In that case, enable the account in Active Directory Users and Computers first, then rerun the repair.

Resetting the Computer Account in Active Directory Users and Computers

The server-side lever is Reset Account on the computer object. In Active Directory Users and Computers, open the computer's OU, right-click the computer, and choose Reset Account. That resets the machine password on the domain side; the client's cached password is then stale, and the next domain logon fails unless you follow with Test-ComputerSecureChannel -Repair from the client, or rejoin the machine. Reset Account is the correct tool when the object exists but the channel is broken and a rejoin is undesirable — for example, on a machine with a long build history where a rejoin would rerun provisioning scripts.

The order matters. Reset Account first, then repair from the client, then reboot. Reversing it leaves the client holding a password the domain has just replaced, which produces the same error and wastes a support call.

Version-specific detail that catches admins on older estates: Reset Account exists in the Active Directory Users and Computers console shipped with Windows Server 2008 R2 and later, and the console connects to any domain controller at Windows Server 2003 functional level or higher. If you administer from RSAT on a client, the Reset Account option appears only when the console is opened against a writable domain controller — a read-only domain controller in a branch office will not offer it, and an admin connected to an RODC will conclude the option is missing when it is simply unavailable there.

For scripted fixes across many machines, Reset-ComputerMachinePassword in the ActiveDirectory PowerShell module (Windows Server 2012 and later) resets the machine password without touching the account's other properties. A worked estimate: the manual GUI rejoin takes about 4-6 minutes per machine including reboots, the Test-ComputerSecureChannel -Repair route about 2-3 minutes, and a scripted Reset-ComputerMachinePassword plus restart runs roughly 90 seconds per machine. Across 40 machines, that is a difference of over two hours — which is why scripted resets are standard in enterprise environments.

Deleting and Recreating the Account Without Wrecking Group Policy

If the computer account is gone, disabled, or duplicated, resetting it does nothing. Deletion and recreation is the repair, but it has a cost most guides do not mention: the new object gets a new SID, and anything that referenced the old SID — Group Policy loopback settings, security filtering on GPOs, file-share permissions granting the machine account, SCCM or Intune device records, certificate autoenrollment tied to the machine — stops applying.

Before deleting, record the machine's current OU and any GPOs whose security filtering explicitly names the computer account. After recreation, the machine drops into the default Computers container unless you pre-stage it in the right OU. The standard practice is to create the computer object in the correct OU before joining, then join with the machine — the join attaches to the pre-staged object and preserves OU placement.

A duplicate account is a special case. If two objects exist with the same name, AD allows it but the join may attach to either one, producing intermittent trust failures that look random. Search for duplicates with Get-ADComputer -Filter "Name -eq 'MACHINENAME'" and delete the stale one before rejoining. This is the scenario where a machine works for a week, fails, works again after a rejoin, and fails again — the pattern that wastes the most support time.

Permissions to watch for on the deleted-and-recreated machine: share permissions granting DOMAIN\MACHINENAME$, scheduled tasks running as the machine account, and SQL Server logins mapped to the old SID (orphaned users in SQL Server are the classic symptom). None of these are fixed by the rejoin itself, and each has its own repair path in its respective tool.

Fast Startup, Restored Snapshots, and Other Recurring Causes

The trust failure that returns after every fix is a different problem from the one that appears once. Recurrence points at a cause outside the machine account password. The three recurring culprits are Fast Startup, VM snapshot restores, and cloned machines.

Virtual machines are the largest source of repeat offenders. Restoring a VM snapshot rolls the guest's machine password back to the snapshot's date, while the domain's copy has moved on — the trust breaks on the next boot. Cloning a VM without sysprep /generalize produces two machines sharing one computer account and one password; both boot, both fight over the account, and the trust fails for whichever loses. VMware and Hyper-V both document the sysprep requirement, and it is the step most often skipped in test environments.

A related trap is the machine renamed through an image-based deployment that changes the computer name but not the machine SID. Renaming a domain-joined machine from outside the domain (for example, by editing registry keys in an image) leaves AD with an object named for the old machine and a client claiming the new name, which reads as a trust failure. The fix is to rejoin cleanly, and to fix the deployment pipeline so it syspreps.

If the failure recurs on the same machine within days of each repair, run Test-ComputerSecureChannel -Verbose daily for a week and log the result with its timestamp. A channel that goes False without a reboot is a password rotation problem — check the MaximumPasswordAge value and any password-change scripts touching the computer object. A channel that goes False only after shutdown is Fast Startup or a snapshot. A channel that goes False after a network change is DNS or time.

Using netdom and Other Command-Line Fallbacks

netdom resetpwd is the command-line equivalent of the client-side repair and works on machines where PowerShell remoting or the module is unavailable. The syntax is netdom resetpwd /Server:DCNAME /UserD:DOMAIN\AdminAccount /PasswordD:* — the asterisk prompts for the password rather than taking it on the command line. It is part of the Remote Server Administration Tools and is not present by default on client Windows, which is why it is less common than the PowerShell route in modern estates.

nltest /sc_query:DOMAIN tests the secure channel and nltest /sc_reset:DOMAIN resets it, and both ship with Windows without extra tooling. The query returns the channel's status and the domain controller it is talking to, which is useful when you suspect the client is contacting a different controller than the one holding the current password. nltest /sc_verify:DOMAIN performs the verification check and reports the last successful verification.

Time skew breaks the repair as often as it breaks the original trust. Kerberos tolerates a default maximum clock skew of five minutes; a machine whose clock is off by more than that fails authentication even after a perfect password reset. Check with w32tm /query /status and resynchronize with w32tm /resync /force before concluding the repair failed.

A few failure cases to recognize. The repair fails with "Access is denied" when the account you supply lacks rights on the computer object — delegate Reset Password and Write on the object, or use Domain Admin. It fails with "The specified account does not exist" when the object is deleted, pointing you to the recreate path. It succeeds but the error returns at next logon when you repaired without rebooting, or when Fast Startup intervened. And it fails on machines forced through a read-only domain controller when the change cannot replicate back to a writable one — check replication with repadmin /replsummary if the domain has RODCs.

Choosing the Right Fix for Your Situation: A Comparison

The right fix depends on two facts: whether the computer object still exists in Active Directory, and whether a rejoin is acceptable in your environment. The table below maps the common situations to a repair, its typical duration, and what it touches.

The fastest repair is the one that matches the cause, not the one with the fewest steps. Repair first when the account is intact; rejoin when it is not; script when the count is high. Skip a domain rejoin on any machine where a new SID breaks something you cannot re-provision quickly — the rejoin fixes the trust and quietly breaks a share permission.

Preventing the Next Trust Failure

Prevention is mostly about closing the three recurring gaps: machines aged past the password rotation window, VMs without sysprep discipline, and Fast Startup left on across a fleet. None of these need new tooling; they need a policy and a check.

For the rotation gap, measure it. Query AD for computer accounts whose pwdLastSet is older than 60 days — a healthy domain-joined machine rotates every 30. Microsoft's Get-ADComputer -Filter {PasswordLastSet -lt (Get-Date).AddDays(-60)} returns them with the built-in AD cmdlets. A machine that never rotates is either failing its own secure channel or being restored from stale state, and both predict a future trust failure.

For VM discipline, make sysprep a hard gate in the image pipeline. Every clone should generalize, every snapshot restore should be followed by a channel check, and test environments should use a base image dated within the password age window. The cost of one broken VM trust is a 15-minute rebuild; the cost of a pipeline that skips sysprep is intermittent trust failures you cannot reproduce on demand.

For Fast Startup, either disable it by Group Policy across managed fleets or accept that the first shutdown of every machine is a coin flip until the next restart. Microsoft documents the Fast Startup behavior and the restart requirement, and the fix is a single policy setting.

Finally, know the cost boundary. A trust failure costs a user hours of lost work and a support ticket; a scripted fix costs under two minutes. The cheap fix is not the one with the fewest keystrokes — it is the one that runs before the user notices. That is why enterprises script the reset and let the GUI rejoin serve as the break-glass path.

FAQ

What does this error actually mean in one sentence?

The workstation's password for its own computer account no longer matches the password Active Directory holds for that account, so the domain controller rejects the logon. The security database is the domain controller's copy and the workstation's cached copy of the same password. The failure is a mismatch, not a deletion in most cases.

Does restarting the computer fix it?

Sometimes — specifically when Fast Startup cached a stale machine password. A full restart rather than a shutdown clears the hybrid cache and re-establishes the channel without any AD change. On Windows 10 and 11, a shutdown is not a restart; the difference is the hiberfil.sys session that Windows restores.

Will a simple password reset on the machine account fix this?

It fixes the mismatch only if the account still exists and the client-side password is the stale half. If the account was deleted, or was disabled, a password reset changes nothing because there is no matching object to authenticate against. Match the tool to the cause before running it.

Can I fix this without domain administrator rights?

You can get a local session and diagnose, but the repair needs rights on the computer object — Reset Password and Write, or Domain Admin. Delegating those rights on a specific OU is the standard alternative to handing out full admin rights across the domain, and it is auditable.

Why does the error come back a few days after I fix it?

Recurrence points to Fast Startup, a VM snapshot restore, or a cloned machine sharing the accounting. Check whether the channel fails only after a shutdown, only after a restore, or on two machines with the same name. Each maps to a different fix, and none of them is another rejoin.

Is this the same as a domain controller trust issue?

No — a domain controller that has lost its trust is a server-wide failure affecting authentication for many clients, and the message about the security database appears on the controller itself. Workstation trust failures affect one machine. Investigate the DC's dates and replication before treating it as a workstation problem.

How long should a repair take?

Two to three minutes for the client-side repair, four to six for a full rejoin, and about 90 seconds per machine for a scripted reset. Budget an extra reboot each time, and add time if Group Policy must reapply at join. A repair that takes 15 minutes on one machine is normal; one that takes 15 on every machine signals a pipeline issue.

Does this happen on workgroup machines or Macs?

No. The error requires an Active Directory domain relation, so it's a Windows domain-joined or AD-bound device scenario. A Mac joined to AD has an analogous trust, but the wording about the security database is specific to Windows clients and the Netlogon error family.

This article is general educational information about Active Directory troubleshooting and is not a step-by-step instruction set for any specific regulated environment. Resetting or deleting computer accounts affects authentication and access control organization-wide, so involve a qualified local IT administrator who holds the appropriate permissions before making changes in production. No outcome or recovery is guaranteed, and no configuration should be treated as approved without your organization's change management and security policies.