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):


  1. vlad

    Hi Andrew,

    Could you please elaborate on, this statement, ” Only use forms if you are using FBA (DO NOT SET THE LIFETIME SHORTER THAN THE EXPIRATION WINDOW):”

    We are using both AD and FBA, and I noticed that very often the group membership isn’t getting updated or even worse, certain folders in the libraries, users dont’ have access to even though according to the, Check permission they do from one group, but not from the other.

  2. Rich

    Hi Andrew,

    Thanks for this!
    Should the token lifetime and expiration remain so short or is this something to do for a quick fix before reverting back to the original settings? Can you briefly explain what these do? It sounds like they would automatically log a user out after a minute or two!


  3. Andrew Billings

    It’s been a while since I wrote this post! As always do some testing in DEV/TEST to see if changing these values makes sense for your organization. I have heard of users getting auth prompts if being too aggressive with changing the timeouts. This solution seems more of a quick fix/set it back to original settings since I haven’t found a way to fix one specific user yet

Leave a Reply

Your email address will not be published. Required fields are marked *