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 '13 at 6:25

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 '13 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) – Heinrich Ulbricht Oct 7 '13 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. – Heinrich Ulbricht Oct 7 '13 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, privacy policy and cookie policy

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