If a user still has access in SharePoint after being removed from an Active Directory group, the issue is often not related to permissions misconfiguration.
In most cases, the cause is SharePoint security token caching.
A real-world scenario
A manager contacts me about a user who still has access to a SharePoint site even after the AD admin removes him from an AD group.
First, he checks the situation using Check Permissions. As expected, the tool shows that the AD group grants access to the user.
However, this result creates confusion because the system already removes the user from that group.
Before contacting me, the manager speaks with a developer. The developer assumes that SharePoint applies permission changes immediately.
However, this assumption is incorrect in SharePoint On-Premises environments.
Why this happens
SharePoint does not validate Active Directory group membership in real time. Instead, it generates and stores a security token during authentication.
This token includes the user’s group memberships at login.
As a result:
- The user continues to access content
- SharePoint still shows permissions coming from the group
- Active Directory changes do not appear immediately
Why Check Permissions can be misleading
The Check Permissions tool reads the current security token instead of querying Active Directory live.
Therefore, SharePoint still treats the user as a group member while the token remains valid.
In other words, the tool reflects cached data, not the current directory state.
Resolution and Outcome
After I explain the concept of token caching, the manager immediately understands the situation.
He realizes that:
- The behavior is normal.
- The delay is expected.
- No permission issue exists.
By default, the cache duration lasts ten hours.
Then, I explain that I can reduce this delay to one hour.
Consequently, his response is simple:
Ten hours is a lot, but I can live with one hour.
It is a great compromise. You get reasonably fast access revocation without putting unnecessary stress on your infrastructure.
How to reduce the delay
You can reduce the security token lifetime in SharePoint On-Premises using PowerShell:
$sts = Get-SPSecurityTokenServiceConfig
$sts.WindowsTokenLifeTime = (New-TimeSpan -Minutes 60)
$sts.Update()Be careful: Lower values increase authentication load and can impact performance in large environments
Force Immediate Effect
If you need the change to apply immediately to all users, you need to reset IIS on all SharePoint front ends:
iisreset
This forces users to re-authenticate and receive a new token.
Warning: This operation interrupts all active sessions and should be used with caution in production environments.
Best Practices
- Understand SharePoint caching behavior.
- Do not rely solely on Check Permissions.
- Inform stakeholders about delays.
- Adjust token lifetime only when necessary.
Conclusion
If a SharePoint user still has access after being removed from an AD group, the root cause is usually security token caching. This is expected behavior and once understood, this issue becomes easy to manage.
Run this PowerShell fix and your SharePoint environment will start checking back with AD much more reasonably.
Next time someone reports a user with lingering access, you will know it will resolve itself within the hour.
Tired of chasing phantom permissions?
Managing complex SharePoint environments shouldn’t feel like a constant battle against your own cache settings.
You are looking to audit your security structure and streamline your permissions?
I am here to help you.
Let’s build a more efficient, secure environment together.
Get in touch with me to discuss your project or schedule a quick consultation.
