ERROR_NON_ACCOUNT_SID (0X000004E9) fix – not an account domain

You're probably staring at this error after messing with user permissions or moving a machine between domains. Annoying, right? Let's fix it.

I've seen this in the wild maybe 15 times. Last month, a client tried to migrate a user from an old domain to a new one, and bam – the user couldn't even log in. The event log showed 0X000004E9.

Here's the short version: Windows checks if a security identifier (SID) belongs to a valid account domain – usually a domain controller or the local SAM. If it doesn't recognize the domain part, it throws this error. You'll see it in event logs, PowerShell scripts, or when you try to assign permissions to a user that doesn't exist anymore.

The fix: Delete the orphaned SID or rebuild the user profile

1. Find the bad SID: Open Event Viewer → Windows Logs → Security. Look for Event ID 4673 or 4776 with 0X000004E9. The SID is usually in the details. Write it down.
2. Check if it's a domain SID or local SID: If it starts with S-1-5-21-... and you don't recognize the domain, it's likely orphaned. If it's a local user SID like S-1-5-32-..., you might have a corrupted user profile.
3. For orphaned domain SIDs: Open ADSI Edit (adsiedit.msc) on a domain controller. Connect to the Default Naming Context. Expand your domain → CN=Users. Find the user object that matches the SID. If it doesn't exist, the SID is dead. Delete any references to it from ACLs using icacls or from the registry under HKEY_LOCAL_MACHINE\SAM\SAM\Domains\Account\Users\Names (you'll need to take ownership of SAM hive).
4. For local user profile corruption: Go to HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList. Look for a key with a long SID that matches the error. If there's no .bak version, rename the key to .old. Reboot and the user will get a fresh profile.
5. Still stuck? Use PsGetSid.exe from Sysinternals to map the SID to a name: psgetsid S-1-5-21-123456789-1234567890-123456789-500. If it returns "Account not found", you've got a ghost SID.

Why this happens

The SID has two parts: a domain identifier and a relative ID (RID). The domain identifier is like the zip code for the account. If you delete a domain or move a user to a different domain, the old SID's domain part doesn't match anything. Windows is strict – it won't let you use a SID that points to a non-existent domain. Same thing happens if the NTUSER.DAT file in a user's profile gets corrupted and references a SID from a previous domain join.

I had a client once where a sysadmin accidentally deleted a domain controller that held the FSMO roles. All user accounts from that domain became ghosts. Every time someone tried to set permissions using those old SIDs, the error popped up. We had to export the SIDs, delete the domain object from AD, and re-add users with fresh SIDs.

Less common variations

• SharePoint or SQL Server: If you see this error in SharePoint logs or SQL Server's error log, it's usually because a login or user was created from a domain that no longer exists. Drop the login/user and recreate it.
• File server ACLs: You might get this when trying to view permissions on a folder. The ACL contains a SID from a domain you no longer trust. Use icacls "C:\Folder" /remove /sid S-1-5-21-... to strip it.
• Windows Hello or certificate services: Rare, but I've seen it when a certificate template references a security group that's missing its domain. Delete the old template or reassign the group.

How to stop it from coming back

Prevention is boring but saves headaches:

• Never delete a domain or user without cleaning up SIDs first. Before removing a domain, use Active Directory Migration Tool (ADMT) to migrate users and SID history. That way old SIDs still resolve.
• When you decommission a server, clean its ACLs. I use SetACL.exe to scan for orphaned SIDs and remove them automatically.
• Keep a record of all domains and trusts. If a trust breaks, you'll know which SIDs to hunt down.
• For local machines, avoid deleting user profiles manually. Use System Properties → User Profiles → Delete. That cleans up the registry properly.

One last thing: if you're in a hurry and just need the error to go away, you can often restart the Netlogon service on the affected machine. It forces a re-authentication of the SID. Works maybe 30% of the time, but it's worth a shot before diving into registry edits.

Hope this gets you back to work. I've been there – staring at a cryptic error at 2 AM. You'll beat it.