Here’s an interesting scenario I hadn’t experienced before: SharePoint 2013 farm doing a user profile sync with Active Directory. Security was based on Active Directory security groups managing membership and authorization controlled through SharePoint groups containing the AD groups. As users were added and removed to/from the AD groups, they weren’t seeing the change reflected in the SharePoint sites. After a crash course in claim caching, here’s what we ended up with.

First, an admittedly simplistic view of how SharePoint manages tokens:

User browses to SharePoint site

SharePoint checks local token store (STS) for a non-expired cached claim for that user

If not found, STS creates a new claim by querying AD and then adds it to the cache

If found, uses the cached claim

That covers the user, now lets look at how SharePoint syncs with AD to get group and membership info. Managed by the User Profile Sync service, SharePoint queries AD to learn about new or removed users as well as group membership. This is also controlled by a cache, and can create the scenario we ran into where AD users that were added or removed from AD groups did not have their authorization permissions updated in SharePoint.

By default, SharePoint will cache this group membership info for 24 hours. Well, we weren’t that patient. We changed it to two minutes using the following command:

That sets the timeout to two (2) minutes. Admittedly a bit extreme, but we’ll set it back to a more reasonable timeframe when things aren’t so volatile.

So that takes care of SharePoint becoming aware of AD group permission changes, but how about user claims being updated? If SharePoint is aware of a user now being granted access through membership in an AD group, but that user obtained their claim earlier in the day before the AD group membership was changed, they will still be denied access. To change that we looked at setting the LogonTokenCacheExpirationWindow and WindowsTokenLifetime properties for the STS:

The above is telling the STS that claims tokens are good for one (1) minute. WindowsTokenLifetime – LogonTokenCacheExpirationWindow, so 2 – 1 = 1. I’m pretty good with math. Default for both is 10 hours.

Oh, if you happen to set a lifetime that is shorter than the expiration window, that’s a good way to block users from accessing the site. Once their existing token expires, they’ll start seeing a message “The context has expired and can no longer be used.”

In other words, don’t do that.

Now every minute STS will refresh the claim token for a user to get the latest and greatest membership info from AD. That seemed to do the trick for this scenario, and we’ll definitely adjust the values above when things aren’t so volatile, but for now we’re looking good.

Hi thanks for a useful blogpost, I have a question as a newbie on powershell.
Is there a way in powershell to just check the token time for my SP site?
I just wanna check what the timer is set to on my SharePoint intranet.

stsadm.exe : The term ‘stsadm.exe’ is not recognized as the name of a cmdlet, function, script file, or operable
program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
At line:1 char:1
+ stsadm.exe -o setproperty -propertyname token-timeout -propertyvalue 2
+ ~~~~~~~~~~
+ CategoryInfo : ObjectNotFound: (stsadm.exe:String) [], CommandNotFoundException
+ FullyQualifiedErrorId : CommandNotFoundException

I tried to run the command Brian provided and I got the “Content has expired error”. I have set the TokenTimeout as 120 minutes. Once the users got kicked out the site with the above error I set the TokenTimeout back to 24 hours and everything was working fine.

I got this error on subsites in a site collection but not on the root site. This web application was claims but the site collection was in 2010 mode.

Hi, i have a doubt, i manage the access to a sharepoint site by groups, but when a change is made in the group, for example remove one persona from the group, this is not reflected after the sync profiles from AD and even after the user log-off log-on, i run this scripts and works to sync for new users on the group but the removed users still has access to the site and they are not belong any more to the AD group. Any ideas?

The above is telling the STS that claims tokens are good for one (1) minute. WindowsTokenLifetime – LogonTokenCacheExpirationWindow, so 2 – 1 = 1. I’m pretty good with math. Default for both is 10 hours.

I believe this is an incorrect statement, one is 10hours and one is 10mins

We have an issue where AD groups were recreated, in this case we need to wait for 24 hours sharepoint app to work normal. We tried to change the token time out to 2 minutes. But this will apply only after 24 hours. Is there anyway to force reset the token time out value so that users no need to wait for 24 hours.

Please advise on this, we have this problem couple of times where operations struck for a day in both cases.

Run the block of statements above in SharePoint Management Shell. It includes an ‘iisreset’ command to force the changes to take effect. If you host other websites in IIS and can’t afford to reset it mid-day, omit that line and try manually restarting SharePoint services instead.