When This Error Shows Up
You're staring at a Windows Server 2019 or 2022 domain member—say a file server or SQL box—and it just won't let you log in. Not even with domain admin credentials. The error code you get: STATUS_NOLOGON_SERVER_TRUST_ACCOUNT (0XC000019A). This isn't a typo. It's a specific case where the system thinks the account trying to authenticate is the server's own machine account—the one that ends with a dollar sign, like SRV-FILES$—and not a real user.
I've seen this most often after a server is cloned, restored from a backup with a different SID, or when someone accidentally resets the computer account in Active Directory Users and Computers but doesn't rejoin the server. The moment you try to log in, the LSASS process sees the credential hash is for a machine account, rejects it, and throws 0XC000019A.
Root Cause
What's actually happening here is that the Kerberos or NTLM authentication path detects the account used in the logon attempt has the USER_SERVER_TRUST_ACCOUNT flag set. In Active Directory, a computer account is marked with this flag—it's not a user, it's a machine. When LSASS receives a logon request that matches a machine account's credentials, it doesn't say "wrong password"—it says "you can't log in with this account type at all." This is by design, not a bug.
The reason it happens post-clone or post-restore is because the local Security Account Manager (SAM) on the server still holds the old machine account password hash (from the previous AD join). The server tries to authenticate using that hash, AD sees it's a computer account, and denies interactive logon. Same thing if you reset the computer object in AD without telling the server—the server's local copy is now out of sync, but AD still sees the object as a machine account.
Fix: Reset and Rejoin the Domain
The only reliable fix is to break the trust and rebuild it. Here's the exact sequence I use. Skip the GUI tools—they're slow and sometimes hide the real problem.
Step 1: Boot into Safe Mode with Networking
Since normal logon is blocked, you need to get in as a local admin. Boot the server, press F8 before the Windows logo, and choose Safe Mode with Networking. Log in with the built-in local Administrator account (the one on the machine, not a domain account). If you don't know that password, you're stuck—reset it via a recovery disk first.
Step 2: Remove the Server from the Domain
Open an elevated command prompt. Run:
netdom remove %COMPUTERNAME% /domain:yourdomain.local /UserD:DOMAIN\AdminUser /PasswordD:* /ForceReplace yourdomain.local with your actual domain. The /Force flag is critical—it forces removal even if AD can't contact the server back. Without it, the command will fail because the trust is already broken.
If netdom isn't available (it's not on Server Core by default), install the AD DS tools first:
Install-WindowsFeature -Name RSAT-ADDS-ToolsStep 3: Reset the Computer Account in Active Directory
On a domain controller (or from a machine with RSAT), open Active Directory Users and Computers. Find the computer object for the server you're fixing. Right-click it, choose Reset Account. This clears the old machine password and sets a new one. Do not delete the object—you lose all group memberships and permissions tied to it.
Step 4: Rejoin the Domain
Back on the problem server, still in safe mode, run:
netdom join %COMPUTERNAME% /domain:yourdomain.local /UserD:DOMAIN\AdminUser /PasswordD:*You'll be prompted for the admin password. After it completes, reboot normally. Log in with a domain user account—should work now.
Step 5: Verify
Check the System event log for ID 5719 or 5805—those indicate trust failures. Also run nltest /sc_query:yourdomain.local to confirm the secure channel is working. You should see The command completed successfully and a status of 0x0.
What If It Still Fails?
Two things I've tripped over:
- DNS mismatch. The server's DNS suffix must match the domain name. Check
ipconfig /all—if the primary DNS suffix is wrong, the server can't find the domain controller. Fix it in System Properties > Computer Name > Change > More. - Time skew. Kerberos requires the server's clock to be within 5 minutes of the DC. Run
w32tm /query /statusand compare. If it's off, sync withw32tm /resync. - Duplicate SID. If you cloned this server, its machine SID is identical to the source. This doesn't break logon itself, but it confuses AD if both are online. Use
Sysprepwith/generalizebefore joining new clones.
If you're still stuck after all that, you've got a deeper issue—maybe a corrupted SAM database or a domain controller replication problem. At that point, back up the data and do a clean OS install. It's faster than diagnosing the last 2% of weirdness.