Fix 0XC0000357 Machine Account Error

This error appears when a domain machine account was created on an old NT4 system. You'll need to reset the account or delete and rejoin the domain. Here's the direct fix.

Yeah, that error's a pain in the neck. But the fix is straightforward, so let's get to it.

The Direct Fix

You have two options, depending on whether you can log into the machine locally or not. Both end with the same result: a fresh machine account.

Option 1: Reset the Account from a Domain Controller (Preferred)

If you have admin rights anywhere on the domain, run this from a domain controller or a machine with RSAT installed:

netdom resetpwd /s:<server> /ud:<domain>\<admin> /pd:*

But honestly, netdom is clunky. Easier is to just delete the computer object in Active Directory Users and Computers, then rejoin the domain from the client.

Open Active Directory Users and Computers (dsa.msc).
Find the affected computer account, right-click, and choose Delete.
On the client machine, leave the domain: Settings > Accounts > Access work or school, then disconnect from the domain. You'll need local admin credentials.
Rejoin the domain using the same name. It'll get a fresh account.

Option 2: If You Can't Get Into Windows

Boot with a local admin account (safe mode works), then run this in an elevated PowerShell:

Remove-Computer -WorkgroupName "WORKGROUP" -Force
Add-Computer -DomainName "yourdomain.local" -Credential (Get-Credential) -Restart

The first command drops the machine out of the domain, clearing the old account binding. Then you rejoin fresh.

Why This Works

What's actually happening here is the domain sees a machine account that was originally created on a Windows NT 4 system. The security identifier (SID) structure and password hash on those old accounts aren't compatible with how modern AD validates the secure channel.

The reason deleting or resetting the account works is that you're wiping out that old NT4-era credential. When the machine rejoins, AD creates a new account with a current password hash and updated SID version. The secure channel can then authenticate properly.

Don't bother trying to reset the machine password via net user or registry hacks — those don't touch the AD-side account descriptor where the problem lives.

Less Common Variations

Sometimes the error shows up not on a fresh join, but during a routine login or when a service tries to access network resources. That happens when the machine account got corrupted or was duplicated by cloning a VM.

VM Clones

If you cloned a VM without running Sysprep, all clones share the same machine account SID. One of them will hit this error. The fix is the same — reset or delete the account for the clone, but also make sure you run Sysprep before future clones.

Account Corrupted by a Botched Password Reset

If someone previously tried netdom resetpwd incorrectly, the account can be left in a weird state that triggers 0XC0000357. Don't fight it; just delete and re-add.

Prevention

You won't see this error often, but when you do, it's almost always because someone resurrected an old VM or a domain controller was restored from a backup created years ago. To keep it from happening:

Never restore a domain controller from a backup that's older than the tombstone lifetime (default 180 days).
If you're cloning VMs, always sysprep them first. No exceptions.
Keep a written record of machine account names when decommissioning hardware — you might reuse them, and you'll want to delete the old AD object first.

That's it. Reset, rejoin, move on. You'll be back in business in under five minutes.