Nested AD Groups not propagating permissions

Question

I have a list of AD Groups that are nested within each other and if I assign a permission level to the top leveled group, the individuals don't seem to get the access they need. Here's an idea of how it works:

Individual A SubGroup B contains Individual A Group C contains SubGroup B

Group C is given access, and Individual A doesn't have access. However, if I assign the Individual A access directly then he/she has it.

Any ideas on why that is, or what is going wrong?

Answer 1

Answer: One of the groups is not setup as a security group in Active Directory.

This still applies to all versions of SharePoint and is most common for nested sub-groups.

To verify: Contact the team which maintains AD or check yourself using a tool like ldp: Ldp Overview.

Then, change the group to be a security group!

Other issues:

If you cannot find the group in the people picker at all

1. Check it is a security group
2. Check that you can find a different group in the same domain
3. If not able to do #1 and #2 above, you will need to verify you have configured the server to search the domain you are expecting. See Configure People Picker in SharePoint 2013.

Answer 2

If your AD group is a security group and you are using SharePoint 2013, the way that AD Groups work are a little different. Each time a user logs into to SharePoint, they receive a token that is their identity for the AD groups they are involved with. There is a property of the Security Token Service called Windows Token Lifetime which is the expiration of the token which then grabs a new token with any new changes to their membership. The default time is 10 hours. Use can check this using:

$sts = Get-SPSecurityTokenServiceConfig
$sts.WindowsTokenLifetime

The LogonTokenCacheExpirationWindow is the amount of time that SharePoint will allow as a buffer for that Token. To change it to check/expire quicker, use the following powershell.

$sts = Get-SPSecurityTokenServiceConfig
$sts.WindowsTokenLifetime = (New-TimeSpan -Minutes 15)
$sts.LogonTokenCacheExpirationWindow = (New-TimeSpan -Minutes 15) 
$sts.Update()

Answer 3

If you have deleted the Security Group and then undeleted using AdRestore or similar, then even though the SID remains the same, SharePoint 2013 sees it as a new group and you have to add the permissions again.

This is evident as you are able to pick the group using the people picker even though it is already picked and listed on the Member list!

Answer 4

I know this one is old but I just want to give a hint about the Windows Token Lifetime you've mentioned: If you decrease this value in the range of minutes, users which are working on a wiki page to write e.g. an article, will lose their work completely when the Token will be renewed.