The Security Database On The Server Workstation Trust Relationship

Why Domain-Joined Workstations Lose Their Trust and How to Fix It

You log into a domain-joined computer one morning and get an error message about the security database not having a trust relationship. It happens less often than people think, but when it does, it stops everything. Email, file shares, mapped drives, anything requiring domain credentials. The computer simply cannot authenticate itself against the domain controller anymore. The trust relationship between a workstation and the domain is maintained through a computer account stored in Active Directory. Each domain-joined machine has a corresponding computer object with an associated password, and this password changes automatically every 30 days by default. The local Security Accounts Manager database on the workstation stores a copy of this password, and both sides must agree on it at all times. When they don't, the secure channel breaks and you get the error about the security database on the server workstation trust relationship not existing or being invalid.

The Security Database On The Server Workstation Trust Relationship

Most IT people know the basic fix: unjoin the domain, then rejoin it. That usually works. But the quick version of that process takes longer than necessary if you do it by hand through the Control Panel. Here is the faster way, assuming you have local administrator access on the stuck machine and domain admin rights to create computer objects. Open PowerShell as an administrator and run: $machine = $env:COMPUTERNAME
$cred = Get-Credential
Remove-Computer -ComputerName $machine -UnjoinDomainCredential $cred -Force
Add-Computer -ComputerName $machine -DomainName "yourdomain.com" -Credential $cred -Force

This does the full unjoin and rejoin in one sequence. It resets the local SAM entry for the computer account and creates a fresh secure channel with the domain. On a typical network this takes about 2 to 5 minutes. If the domain controller is reachable and replication is healthy, that is usually all you need. There is a slightly different approach if you want to avoid a full unjoin. You can use the Net command to reset the machine account password directly: netdom resetpwd /server:yourdomain.com /userd:DOMAIN\AdminUser /passwordd:*

This asks the domain controller to update the computer account password without removing the machine from the domain entirely. It works when the secure channel is partially broken but the computer object still exists in Active Directory with valid permissions. It is faster than a full rejoin, usually under a minute. But it does not work if the computer object itself is corrupted or missing from AD. In those cases you need to go the unjoin/rejoin route. I ran into a situation last year where netdom failed on a batch of about a dozen workstations that had all been reimaged from the same golden master. The problem was not a single broken trust relationship. The entire deployment process had skipped Sysprep, so every cloned VM had the same machine SID and the same embedded computer account credentials. The domain controller accepted the first join, then rejected every subsequent one because the SID collisions created conflicting computer objects. Cleaning up the duplicate objects in Active Directory Users and Computers did not help because the local SAM data was also identical across all machines. The only working fix was to disjoin each machine, delete the leftover computer object from AD, and rejoin with a fresh SID. Once Sysprep was added to the build process, the problem stopped happening. Another edge case involves laptops that travel between offices. These machines occasionally lose their trust relationship after being offline for extended periods. The 30-day password change cycle runs on a timer, and if the machine is away from the domain long enough, the password rotates on the domain side while the local copy stays stale. When the laptop finally connects again, the secure channel fails immediately. Disjoining and rejoining fixes it, but it is cleaner to just let the computer re-authenticate if you catch it early. Running nltest /sc_reset:DOMAIN from an elevated prompt sometimes forces a password sync without a full rejoin. It does not always work, but it is worth trying before going nuclear.

Here is something most guides do not mention. The trust relationship can break even when nothing obvious has changed. I have seen this happen after a Windows Update group policy refresh went wrong on a workstation, corrupting the cached credentials in the local SAM. The machine would boot fine, but any attempt to validate against the domain failed silently. A normal rejoin fixed it, but the real issue was that the corrupted SAM entry persisted across reboots until the computer object was recreated. Running a manual sfc /scannow did not help because the corruption was in the security descriptor, not system files. This is rare enough that you should not lose sleep over it, but if a rejoin fails repeatedly on the same machine, check the event logs for Event ID 5719 or 5805, which indicate secure channel failures at the kernel level. The downsides of relying on unjoin and rejoin are real. You lose local Group Policy preferences tied to the machine account. Any software installed with machine-level installation contexts may need reconfiguration. User profile folders do not get deleted, but the OS may create a new profile on next login if the SID changes in a way the local cache does not recognize. For most deployments this is acceptable, but in environments with locked-down imaging standards or compliance requirements, the downtime matters. In those cases, keeping computer account passwords in sync through GPO or using a centralized configuration management tool reduces the chances of this happening in the first place. There is also a scenario where the unjoin/rejoin method simply will not work. If the domain controller is unreachable, if replication between DCs is broken, or if the domain itself has a structural problem in the NTDS database, no amount of local remediation will restore the trust. I dealt with one case where a poorly configured DFS namespace caused the workstation to target a stale DC for authentication. The DC returned errors that looked exactly like a trust relationship failure. The actual problem was a DNS recording that pointed to a decommissioned server. Fixing the DNS record fixed the trust issue without touching the domain membership at all. This is why you should always verify connectivity to a known-good domain controller before assuming the trust relationship itself is broken.

The practical takeaway is straightforward. Most trust relationship failures resolve with a clean domain rejoin. A small percentage need the computer object cleared from Active Directory first. A smaller percentage are caused by something else entirely, usually infrastructure. Checking the event log, confirming DC reachability, and ruling out DNS problems should take less than five minutes and saves you from doing unnecessary rejoins.