You've seen this ticket a hundred times:

"IT added me to the share group. I still get Access Denied."

Permissions look right in AD or Entra. The share ACL looks right. The user is sure they're in the group. And yet… Access Denied. 😤

Usually nothing is "wrong" with the permissions. The PC is still holding yesterday's security token.

🔍 Step 1: Prove the group membership on the PC

Don't trust the portal alone. Check what this Windows session thinks:

whoami /groups

Or filter for the group name:

whoami /groups | findstr /i "FinanceShare"
  • Listed? Membership made it to the device. Move to Step 2.
  • Missing? AD/Entra sync may still be catching up, or the user was added to the wrong group. Fix that before you chase tokens.

🔄 Step 2: Full sign-out (Lock is not enough)

Windows builds your access token at logon. That token carries your group SIDs. Locking the screen keeps the same token. So:

  1. Sign out of Windows completely (Start > account > Sign out).
  2. Sign back in.
  3. Retry the share or app.

For Entra-joined devices, a full sign-out/sign-in is what refreshes the modern auth token too. A quick lock/unlock won't cut it. 💡

⚡ Step 3: Purge stale Kerberos tickets for file shares

If it's a classic SMB/file share and they're still blocked after a fresh logon:

klist klist purge

Then reconnect to the share (open \\fileserver\share again). Kerberos will request a new service ticket with the updated groups.

Prefer PowerShell for the reconnect check?

Test-Path \\fileserver\share Test-NetConnection fileserver -Port 445

If port 445 fails, you're in DNS/VPN/firewall territory — not permissions.

🧰 Bonus checks that save escalations

  • Nested groups: user → nested group → share group. whoami /groups should still show the effective group if token is fresh.
  • Share vs NTFS: Access Denied can come from either layer. Confirm both.
  • Cached credentials: Credential Manager may still have an old mapped-drive identity. Clear the entry, then remap.
  • M365 / SharePoint: group changes can lag a bit. Hard-refresh the browser, try InPrivate, and confirm the user is in the Microsoft 365 / security group the site actually uses.

🙌 Why this matters

At the help desk, "permissions are fine" often means "the directory is fine." The endpoint is still running on an old token. Teaching users (and yourself) to verify membership → full sign-out → purge tickets closes the ticket without a pointless ACL rewrite. 💪

What's your go-to move when Access Denied survives a "correct" group add? Drop it below 👇