I deleted an Active Directory account named `master` that employees had been using to install software with elevated privileges. The account can no longer be used for an interactive logon, but its credentials still appear to work when launching tools such as Command Prompt under that identity on domain-joined machines. The environment is small and only has a few basic file-sharing policies. I have already tried clearing cached credentials, but the behavior continues. I still have the deleted account's SID and would like to determine whether this is an old logon token, cached authentication, a local account with the same name, or something else.
3 Answers
Cached domain logons and already-issued authentication tokens are separate from Credential Manager. You can review the policy under Local Policies > Security Options > Interactive logon: Number of previous logons to cache, but changing it will not instantly invalidate every existing token. If you temporarily change the cache setting through policy, force the policy update, and restart or log off the affected machines, restore the normal setting afterward. For future administrative accounts, consider using the Protected Users group where compatible and avoid sharing a general-purpose admin account.
Make sure this is not a local account named `master`. Run `Get-LocalUser master` on the machine and compare the identity with `whoami /user`. A local account with the same name could continue working even though the domain account was deleted. Also inspect local group membership for the deleted account’s SID and remove any stale entry.
First verify which identity the existing elevated process actually has. From that Command Prompt, run `whoami /user` and compare the SID with the deleted domain account’s SID. Also check whether `runas /netonly` is being used, since that can start a process without validating the credentials immediately and only uses them for network access. If it is genuinely the deleted domain SID, log off all users or reboot the affected machine to remove existing tokens, run `klist purge`, and confirm the deletion replicated to every domain controller with `repadmin /replsummary`. Check the local Administrators group too, including entries shown only by the deleted SID. Finally, try a fresh `runas /user:DOMAIN\master cmd` while connected to a domain controller; it should fail.
That cleared up a lot. I had been assuming Credential Manager was responsible, but checking the SID makes much more sense.