Windows executable-identity check false-positives on a renamed local Administrator account (RID 500) #1705

Title

Windows executable-identity check false-positives on a renamed local Administrator account (RID 500)

Body

Summary

On a domain-joined corporate Windows machine, both the npm installer (install.js → verifyCandidate/activation) and the native install.ps1 refuse to install, because the binary's own "exact executable identity" / DACL self-check flags an ACE on the user's home directory (C:\Users\<user>) as belonging to an "untrusted identity."

Investigation showed the flagged SID (S-1-5-21-<machine-domain>-500) is not an orphaned or unexpected identity — it resolves cleanly via IdentityReference.Translate()/friendly-name lookup to <COMPUTERNAME>\<renamed-admin-account>. RID 500 is always the built-in local Administrator account; this org's standard hardening practice is to rename it to a non-default name, which is a very common enterprise security practice (CIS/NIST baselines recommend it).

The full ACL on the affected directory was entirely unremarkable:

Root cause (best guess from the outside)

The identity-verification logic appears to hardcode trust for well-known, constant SIDs (S-1-5-18 SYSTEM, S-1-5-32-544 BUILTIN\Administrators), but has no equivalent allowance for a machine's own local built-in Administrator account (RID 500) under its actual machine SID — which is necessarily machine-specific and can't be hardcoded. Since renaming the built-in Administrator account is standard practice in many enterprises, this looks likely to affect a meaningful fraction of corporate Windows users, not just an edge case.

Suggested fix

Treat an ACE whose SID is <local-machine-SID>-500 (i.e., the box's own built-in Administrator/RID 500, regardless of display name) as trusted equivalently to BUILTIN\Administrators, since on Windows the local Administrators group and the local RID-500 account are effectively the same trust boundary. The local machine SID is derivable at runtime (e.g. via LookupAccountName on \\.\ Administrators or reading the current machine SID), so this doesn't require hardcoding anything machine-specific.

Environment

• codebase-memory-mcp v0.10.6 (Windows amd64)
• Windows 11 Enterprise, domain-joined
• Both npm install -g codebase-memory-mcp and native install.ps1 reproduce the same underlying rejection (activation/DACL check), though the npm path additionally surfaces a separate 15s verifyCandidate timeout under load that's a distinct issue from this ACL false-positive.

Happy to provide more diagnostic output if useful — kept identifying details (hostname, domain, account names) redacted/generalized above since this is a corporate machine.