I deleted an Active Directory user named `master`. Employees had been using that account to install software and run programs requiring elevation, which I know is not a good setup. The account can no longer be used for a normal logon, but its credentials still appear to work when launching something like 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 and several other suggested commands, but the behavior continues. I still have the deleted account's SID. What could allow the account to keep working, and how can I determine whether this is an old token, cached logon, a local account, or something else?
3 Answers
First verify which identity is actually being used. From the Command Prompt started as `master`, run `whoami /user` and compare the displayed SID with the deleted domain account’s SID. Also check that you are not using `runas /netonly`; that option can start a process without validating the credentials against the domain until it accesses a network resource.
If the SID matches the deleted account, log off all users or reboot the affected computer to remove existing access tokens, then run `klist purge`. Confirm that the deletion has replicated to every domain controller with something like `repadmin /replsummary`. Also inspect the local Administrators group for the deleted SID and remove it if present.
After the machine can contact a domain controller, try a fresh `runas /user:DOMAIN\master cmd`; it should fail. If it still succeeds, check whether a local account named `master` exists with `Get-LocalUser master`. The SID from `whoami /user` will distinguish a local account from the deleted domain account.
It is worth checking whether `master` is actually a local account, service identity, or account created by some installed software. A deleted domain account and a local account can have the same name but different SIDs, so the `whoami /user` result is the quickest way to tell them apart.
If the account is only being used for elevation, replace the shared credentials with individual administrator accounts and remove the old account from local groups and scheduled tasks. Also check services, scheduled tasks, saved credentials, and deployment tools for references to the old name.
Cached domain logons are handled by the Local Security Authority rather than the ordinary Credential Manager store. You can review the local policy under Local Policies > Security Options > Interactive logon: Number of previous logons to cache. Temporarily lowering that value and having users log on with their own accounts can clear previously cached domain logons, but remember to restore the setting afterward.
This does not invalidate tokens that are already active, so a logoff or reboot is still important. For future administrative accounts, avoid sharing one elevated account and consider using separate named admin accounts. The Protected Users group can also reduce exposure to several credential and ticket-related authentication mechanisms, where compatible with the environment.
Related Questions
Can't Load PhpMyadmin On After Server Update
Redirect www to non-www in Apache Conf
How To Check If Your SSL Cert Is SHA 1
Windows TrackPad Gestures