I know how annoying this error is. You're sitting at your desk, you type your password, and instead of your desktop you get that dreaded message: STATUS_TRUSTED_RELATIONSHIP_FAILURE (0XC000018D). It usually happens after a password reset on the server side, or when someone restored an old VM snapshot. The fix is straightforward, but you need local admin access to pull it off.
The Fix: Rejoin the Domain
- Log in with the local Administrator account. If you don't know the local admin password, you'll need someone in IT to reset it first. On Windows 10/11, press Ctrl+Alt+Del, click "Other user", and type
.\Administratoras the username. Then enter the local admin password. - Open System Properties. Right-click the Start button, select "System", then click "Rename this PC (Advanced)" on the right side. This opens the System Properties window. You can also type
sysdm.cplin the Run box (Win+R). - Change the domain membership. Click the "Change" button next to "To rename this computer or change its domain or workgroup...".
- Switch to a workgroup. Select "Workgroup" and type any name (like WORKGROUP). Click OK. You'll be asked for credentials that have permission to remove this computer from the domain — use any domain admin account. After that, you'll get a welcome to the workgroup message. Click OK, then OK again. Restart the computer when prompted.
- Log back in locally with the local Administrator account after the reboot.
- Rejoin the domain. Go back to System Properties > Change. This time select "Domain" and type your domain name (like
contoso.com). Click OK. Enter domain admin credentials when prompted. You should see a welcome to the domain message. Click OK, then OK again. Restart one more time.
After that second reboot, log in with your normal domain account. You should be good to go.
Why This Works
The error 0XC000018D happens because the computer's machine account password in Active Directory doesn't match what the local machine thinks it is. Every domain-joined computer has a secret password that gets rotated every 30 days by default. If that password gets out of sync — say, from restoring a backup, cloning a VM, or resetting the computer account on the server — Windows won't let you log in.
By leaving the domain and rejoining, you're effectively deleting the old computer account and creating a fresh one with a brand new password. The trust relationship is rebuilt from scratch. It's the nuclear option, but it works every time.
Less Common Variations
Fix Without Rejoining (Using PowerShell)
If you can log in locally but don't want to disjoin and rejoin, you can reset the machine account password with PowerShell. This works if the trust is broken but the computer account still exists in AD. Run PowerShell as Administrator on the affected machine:
Reset-ComputerMachinePassword -Credential (Get-Credential) -Server "YourDomainController.yourdomain.com"You'll be prompted for domain admin credentials. After it completes, reboot. This often fixes the issue without changing the domain membership.
Server-Side Fix (Active Directory Users and Computers)
If you have remote access to a domain controller, you can reset the computer account from there. Open Active Directory Users and Computers, find the computer object, right-click it, select "Reset Account". Then on the affected machine, reboot and log in. This works because the reset clears the old password on the server side, forcing the machine to re-authenticate.
Prevention
- Never restore VM snapshots from a backup that's more than 30 days old. The machine account password changes every 30 days. Restoring an old snapshot puts the password back to an older state, causing the trust failure.
- Use a dedicated service account for automated tasks that reset computer accounts. Don't use domain admin credentials in scripts that run regularly — they can accidentally blow away the trust relationship.
- Monitor for stale computer accounts in Active Directory. Use a script to find computers that haven't changed their password in over 90 days. Disable or remove them to avoid authentication issues.
- Keep a written record of local admin passwords for all domain-joined machines. When the trust fails, you can't log in without local admin access. Store these passwords in a secure password manager.
The bottom line: 0XC000018D is a trust problem, and the fix is either a rejoin or a password reset. Stick to the rejoin method if you want the highest chance of success. The PowerShell reset and server-side reset are faster but less reliable in my experience. And for the love of IT, keep those local admin passwords handy.