Fix STATUS_NO_TRUST_SAM_ACCOUNT (0XC000018B) for SQL Server

When This Error Hits

You're staring at the SQL Server error log or the Windows Application Event Log. Event ID 7031 or 7034 shows up, and the service status is "Stopped." The error code is 0XC000018B, and the description reads STATUS_NO_TRUST_SAM_ACCOUNT. This happens right after a reboot, or after someone changed the computer's domain membership, or after a domain controller restore. The SQL Server service—maybe MSSQLSERVER, maybe SQLSERVERAGENT—refuses to start. It can't authenticate with the domain because the secure channel between the server and the domain controller is blown.

I've seen this most often on SQL Server 2016 and 2019 after a domain controller crash-and-restore from backup, or after a sysadmin renamed the server in Active Directory without properly disjoining and rejoining. The service account itself is fine—the password hasn't changed. The machine account password is the problem.

Root Cause in Plain English

Every Windows machine joined to a domain has a secret password—the machine account password. It changes every 30 days by default. The domain controller stores a copy. The local machine stores a copy. When they don't match, the domain controller sees the machine as untrusted. The SQL Server service, running under a domain account, can't get a Kerberos ticket or NTLM token to prove who it is. The error code 0XC000018B is Windows saying "I don't know who this machine is—no trust exists."

This isn't a SQL Server issue. It's a Windows domain membership issue. The fix is to refresh the machine account password or re-establish the trust relationship.

The Fix: Reset the Machine Account Password

Here's the step-by-step. You'll need local Administrator rights on the server, and a domain account with permissions to join computers to the domain (Domain Admin or delegated).

1. Log on to the SQL Server locally. Use the local Administrator account, not a domain account. If you can't log on because the domain won't trust, use the built-in Administrator (or another local admin you've set up).
2. Open an elevated Command Prompt. Right-click Command Prompt, choose "Run as administrator." Confirm the UAC prompt.
3. Run the following command to reset the secure channel:

   netdom resetpwd /server:<DC_name> /userd:<domain>\<admin_user> /passwordd:*

   Replace <DC_name> with a working domain controller (use FQDN, e.g., dc01.yourdomain.com). Replace <domain> with your NetBIOS domain name (e.g., YOURDOMAIN). Replace <admin_user> with a domain admin account (e.g., jsmith). You'll be prompted for the password. Example:

   netdom resetpwd /server:dc01.yourdomain.com /userd:YOURDOMAIN\jsmith /passwordd:*

   After hitting Enter, type the password. You should see: The machine account password has been reset successfully.
4. Reboot the server. This forces the local machine to re-establish the secure channel with the domain using the new password. Run:

   shutdown /r /t 0

5. After reboot, log on with a domain account. If it lets you log on, the trust is restored. If not, the command didn't work—see the "If It Still Fails" section below.
6. Start SQL Server services. Open Services.msc, find MSSQLSERVER and SQLSERVERAGENT. Right-click each, select Start. Check the SQL Server error log or Windows Event Log for success.

If the netdom resetpwd Command Fails

Sometimes the domain controller you specified is also out of sync, or the command bombs because the machine account is actually deleted in AD. In that case, you rejoin the domain. This is more aggressive—it removes the computer from the domain and adds it back. You lose the machine account SID but not the local profiles or data.

1. Log on locally as Administrator.
2. Open System Properties. Press Windows+Pause/Break, or right-click This PC > Properties > Advanced system settings.
3. Click "Change" under Computer Name/Domain.
4. Select "Workgroup" and type a temporary workgroup name (like WORKGROUP). Click OK. Reboot when prompted.
5. Log on locally again. Open System Properties again.
6. Click "Change" and select "Domain." Enter your domain name. Provide domain admin credentials when prompted. Click OK.
7. Reboot again.
8. Log on with a domain account. Start SQL Server services.

What to Check If It Still Fails

• Is the service account itself locked or expired? Check Active Directory Users and Computers. Unlock the account or reset the password. Update the password in SQL Server Configuration Manager under Services > SQL Server Service > Change Account.
• Is the server's clock out of sync? Kerberos requires time within 5 minutes of the DC. Run w32tm /resync from an elevated prompt.
• Is the machine account object actually missing from AD? Open AD Users and Computers, find the Computers container. If the server's name isn't there, the object was deleted. Rejoining is the only fix.
• Check DNS. The server must resolve domain controller names. Run nslookup yourdomain.com. If it fails, fix DNS first—point the server's DNS to a working DC.
• Firewall rules? Make sure the SQL Server can reach the domain controller on ports 88 (Kerberos), 389 (LDAP), 445 (SMB), and 464 (Kerberos password change).

This error is almost always a trust issue. The steps above fix it 95% of the time. If you're still stuck after rejoining, it's probably a service account password mismatch. Change the service account password in both AD and SQL Server Configuration Manager, then restart.