Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

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?

share|improve this question
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
add comment

2 Answers

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.

share|improve this answer
    
Same situation here. At least iisrest helps as a workaround when testing, thanks for sharing. –  Heinrich Ulbricht Oct 7 '13 at 9:04
add comment

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=Get-SPSecurityTokenServiceConfig
$stsc.LogonTokenCacheExpirationWindow = (New-TimeSpan -second 30)
$stsc.Update()

iisreset /noforce
share|improve this answer
    
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
    
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
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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