I have a test user who is a member of an Active Directory Security Group. I've added that Active Directory group to the a SharePoint Group "[SiteName] Users".

In this scenario, when I attempt to login with the test user it says "This site has not been shared with you." Under site permissions when I hit "Check Permissions" and input the test user's username, it says it has the correct permissions granted by the correct groups.

And when I add the test user directly to the SharePoint group, it works fine - the user can login and has the correct permissions. Hitting "check permissions" shows the same output as when only the Active Directory group is added to the SharePoint group.

Am I setting this up incorrectly or need to do something else?

  • 1
    It's also worth noting (based on additional research), that the AD group in question is not nested. It's in the Global Security Groups OU and directly contains the test user.
    – lukiffer
    Jan 11, 2013 at 6:25

3 Answers 3


After much research, we found that SharePoint not only caches the token for the logged in user, but also for the groups to which that user does or doesn't belong. Setting the cache expiration as described here fixed everything up.

$stsc.LogonTokenCacheExpirationWindow = (New-TimeSpan -second 30)

iisreset /noforce
  • Well it was fixed yesterday, and now we're having the same problem. Verified that the setting was still set to 30 seconds.
    – lukiffer
    Jan 16, 2013 at 0:47
  • 1
    There are more properties you can configure (WindowsTokenLifetime, FormsTokenLifetime), see here: sharepoint.stackexchange.com/questions/14649/… (nice background info as well) Oct 7, 2013 at 10:09

I also have a problem here with Memberships in AD Security Groups. I have a user who has permissions via AD Group Membership on a SharePoint 2013 site. When I delete the user from the AD Security Group he still has access to the site!

This does not happen, when the user is directly added into SharePoint.

I also tried the script mentioned above. But that did not help at all. IISreset helps immediatly. So, delete the user from the AD Group, do an IISreset and there you go. Not really a practicable solution.

  • Same situation here. At least iisrest helps as a workaround when testing, thanks for sharing. Oct 7, 2013 at 9:04

You'd need to setup the token timeout expiration.

Via PowerShell script it would look like:

$sts = Get-SPSecurityTokenServiceConfig
$sts.FormsTokenLifetime = (New-TimeSpan -minutes 10)
$sts.WindowsTokenLifetime = (New-TimeSpan -minutes 10)
$sts.LogonTokenCacheExpirationWindow = (New-TimeSpan -minutes 1)


FormsTokenLifetime and WindowsTokenLifetime are used to specify how long the token would be valid for. Those are observed based on the Authentication type used - Form Based Authentication or Windows Authentication respectively.

LogonTokenCacheExpirationWindow is the smaller value which reduces the value specified above in order to make sure SP triggers a token refresh on time.

Hence actual token lifetime is: WindowsTokenLifetime – LogonTokenCacheExpirationWindow

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.