Fix ERROR_NON_DOMAIN_SID (0x4EA) in Windows

ERROR_NON_DOMAIN_SID means Windows expected a domain SID but got one without a domain component. Usually appears when joining a domain or during account permission checks. Fix by validating SIDs and repairing AD connections.

Quick answer

Run whoami /all and gpresult /h gp.html to find the stale SID, then remove it from the registry or Group Policy — that clears 0x000004EA.

Why this happens

This error shows up when a process passes a security identifier (SID) that has no domain component. Windows expects each SID to include a domain SID prefix (like S-1-5-21-...) that ties it back to an Active Directory domain. When the SID only contains the RID (relative identifier) or is a well-known local SID in a context that requires a domain, you get ERROR_NON_DOMAIN_SID. You'll typically see this during domain joins, when applying GPO security filters, or when a third-party app tries to impersonate a user. I've also seen it after a computer was removed from a domain and re-added — old SIDs linger in registry and permissions lists.

Fix steps

Identify the offending SID — Open PowerShell as admin and run:
```
whoami /all > sid.txt
```
Then open sid.txt and look for any entry with missing domain prefix. Legit SIDs look like S-1-5-21-123456789-123456789-123456789-1001. A malformed one might be S-1-5-1001 or contain a placeholder.
Check Group Policy — Run gpresult /h gp.html and open the file. Look under "Security Groups" or "Filtered GPOs" for SIDs that don't resolve. If you find one, note the GPO name.
Remove stale SID from registry — If the SID appears in HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList, there's likely a leftover user profile. Open regedit, go to that path, and delete the key that matches the bad SID. Back up the key first by right-clicking and Export.
Clean up permissions — If the SID is in a folder's ACL, run:
```
icacls "C:\folder" /remove *S-1-5-1001
```
Replace the SID with the one you found. You may need to use icacls with the full path and quote it if there are spaces.
Reboot — After changes, restart the machine. On reboot, try the operation that triggered the error again.

If that doesn't work

Sometimes the SID is baked into a service or scheduled task. Check services with sc qc <service name> and tasks in Task Scheduler. Look for "Run as" accounts that have a stale SID. Recreate the task or change the service to run as Local System, then test.

Another culprit is a corrupted domain trust. Run nltest /dsgetdc:yourdomain.com to see if the domain controller responds. If it fails, rejoin the domain: remove the PC from the domain, restart, then re-add it. This regenerates the computer SID and drops old references.

Prevention tip

The real fix is to avoid leaving orphaned SIDs behind. When you remove a user or computer from AD, always delete their profile and any mapped drive permissions. Also, use Set-ADComputer to set the ManagedBy attribute correctly if you're automating domain joins — that keeps SIDs tied to a domain. And test any GPO security filters with gpresult before you deploy them to 500 machines.