STATUS_DS_MEMBERSHIP_EVALUATED_LOCALLY (0X00000121) Fix: Group Membership Stale

Cause #1: Stale Kerberos Ticket — the most common culprit

I saw this error constantly when I ran help desk for a mid-size law firm. A user would get access denied to a shared folder or an app, and the event log would throw STATUS_DS_MEMBERSHIP_EVALUATED_LOCALLY. Nine times out of ten, it's a stale Kerberos ticket that your machine is holding onto. Instead of asking the domain controller for fresh group membership info, Windows says "I'll just use what I've got locally." That's the error — a shortcut that backfires.

The fix is dead simple. On the affected machine, open Command Prompt as Administrator and run:

klist purge

This clears all cached Kerberos tickets. Then run:

gpupdate /force

This forces a fresh Group Policy refresh, which also triggers a new Kerberos authentication. After that, log off and log back on. I know it's annoying to log off, but it's necessary — Windows caches your token at login, and the new ticket won't take effect until you do.

If you're on a Server Core install or just want to avoid a reboot, you can also run klist -li 0x3e7 purge to purge the machine account's ticket without affecting user tickets. That's saved me a few times.

Cause #2: Time skew between the client and domain controller

Kerberos is a stickler for time. If the client's clock is off by more than 5 minutes from the domain controller, Kerberos won't trust the ticket. Instead of failing completely, Windows falls back to local evaluation and gives you 0x00000121. I've seen this happen after daylight saving time didn't propagate correctly, or when a VM host's clock drifted.

First, check the time on the problem machine. Run this in PowerShell:

w32tm /query /status

Look at the Source line — it should point to your domain controller. If it says Local CMOS Clock, time sync is broken. Fix it with:

w32tm /resync /nowait

If that fails, restart the Windows Time service:

net stop w32time && net start w32time && w32tm /resync

Also check that the client is pointing to the right DC for time. Run w32tm /query /peers — if you see nothing, reconfigure it with:

w32tm /config /syncfromflags:domhier /update

I've had to do this on every freshly built Windows Server VM for years. Hyper-V and VMware both let host clocks drift, and that cascades into Kerberos errors.

Cause #3: Corrupted token or cached credential

Less common, but I've seen it after a user was removed from an AD group but the old token still hung around. The local machine didn't get the group membership change because the DC had already issued a new token, but Windows kept using the old one.

On the affected machine, run this to check your current token:

whoami /groups

Look for a group you know you shouldn't be in anymore (like a disabled security group or a test group that was deleted). If you see stale groups, kill the token by logging off completely and rebooting. Then force a new token by running klist purge again and gpupdate /force.

If that doesn't work, you can try resetting the machine's secure channel with the domain:

netdom resetpwd /server:<your_dc_fqdn> /userd:<domain_admin> /passwordd:*

Then reboot. This is a nuclear option — I only use it when nothing else helps.

Quick-reference summary table

Hope this saves you the hour I lost the first time I hit this. It's a stupid error — but at least it's easy to squash once you know what's causing it.