SharePoint 2013 Claims Authentication – AD Group changes not reflected

One of the most noticeable differences between SharePoint 2010 and SharePoint 2013 is the default authentication method  is claims authentication, not classic. This is all fine and dandy until you go to add an AD group to a SharePoint site with a user in it. This user no longer needs access to the site so you go ahead and remove the user. You have the user test after lunch and they are still able to access the site. Your gut tells you to run a full User Profile Sync and then a Search Crawl and everything will be alright. After doing all that the user can still access the site…What the F David Blaine!?

When a domain user logs on to SharePoint, the server creates a token that contains information about that user  and any domain groups they are a member of. By default, SharePoint 2010 and SharePoint 2013 will cache this data for 24 hours, at which point the token will expire, and the next user logon will force a fresh token to be created. This is explained here:

You can check the current values of the server’s token timeout with this command:

You should get the following back: <property value=”1440″ exist=”Yes”>

Now if you want to go and change this value here is a sample script to change the value to one hour (60 min):

This will fix the server-side and make SharePoint aware of a user being granted access through membership in AD, but if the user already obtained their claim earlier in the day they may still get access denied. These properties are WindowsTokenLifetime (Default is 10 hours) and LogonTokenCache (Default is 10 minutes).

Here is a PowerShell script to change the Token Lifetime to 2 minutes and Expiration to 1 minute. Only use forms if you are using FBA (DO NOT SET THE LIFETIME SHORTER THAN THE EXPIRATION WINDOW):