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?

  • Im having the same problem. They are both universal security groups in AD, however SharePoint is not seeing them. Very frustrating. Commented Apr 4, 2014 at 4:57
  • Same problem here with 2013. All of the groups are universal security groups. Any idea?
    – jlai
    Commented May 19, 2014 at 12:01

4 Answers 4


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.
  • 3
    That's a good place to look. Distribution lists will NOT import into Sharepoint via the user profile import. Ensure everything is a security group in AD. Commented Mar 9, 2011 at 19:08
  • Thanks guys, I'll look into it and I'll check back really soon.
    – Mike
    Commented Mar 9, 2011 at 20:11

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

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) 

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!


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.

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.