24

I have a SharePoint 2010 Foundation installation on Windows 2008 R2 and SQL Server 2008 and using Claims and Windows authentication.

Subsites are visible only to members of a certain group. However, when I add a user to the AD group that has access to a given subsite, the permissions for that user in SharePoint is not updated before the next day. So there is a mismatch between the permissions in AD and the ones in SharePoint.

For me, it seems like SharePoint is caching the permissions, and only updating them once every day. Is there a way to force a refresh so new permissions are loaded into SharePoint at once?

Improve this question
1

5 Answers 5

Reset to default
21

Configure the Token Cache to a smaller value: http://technet.microsoft.com/en-us/library/cc287917(office.12).aspx. Default is 1440 minutes (24hrs)

Improve this answer
3
7

Original

This may due to the fact that Sharepoint imports the group membership information from Active Directory on a regular basis. the Frequency depends on configuration of your User Profile Synchronization service in central Admin. Profile synchronization is described nicely here: http://technet.microsoft.com/en-us/library/gg188041.aspx#groups

Updated Looking at comments below and carefully reading the link above, I think that AD Group membership is used for while Sharepoint compiled the target audiences. It is possible that even running profile synchronization does not solve your problem. Try using IISRESET /NOFORCE and see if it immediately detects AD changes (and clears the cache). I came across a long thread related to similar problem and I could not find a proper answer. Please share your experience and findings.

Improve this answer
9
  • 1
    @PirateEric for once you cannot compare 2007 user profiles with 2010 since the architecture was changed completely with SP 2010 using FIM. Also read the article, it clearly states that groups are only used for Audiences, not authentication :-)
    – Anders Rask
    Jun 15, 2011 at 21:13
  • 1
    gpupdate /force seems to work as well.
    – Colin
    Jun 16, 2011 at 6:49
  • 1
    I think this has nothing to do with user profile sync. I tried tip suggested by Wictor but it doesnt work in my case
    – Kannan Karmegam
    Jun 17, 2013 at 7:53
  • 1
    This has nothing to do with User profile services. UPS are meant for My sites and social features.
    – Kannan Karmegam
    Jun 26, 2013 at 15:10
  • 1
    iisreset /noforce worked for me on SPS 2013.
    – NekojiruSou
    Apr 7, 2015 at 3:38
7

Hope this will help someone because I faced the same issue. The claims based token is refreshed every 10 hours and hence if you make any changes to Active directory group memberships it won't reflect immediately in the token. you need to run the following powershell command to adjust the token life time to a smaller value.

$sts = Get-SPSecurityTokenServiceConfig
$sts.WindowsTokenLifetime = (New-TimeSpan –minutes 60)
$sts.FormsTokenLifetime = (New-TimeSpan -minutes 60)
$sts.Update()
Iisreset

It is explained in detail here http://www.shillier.com/archive/2010/10/25/authorization-failures-with-claims-based-authentication-in-sharepoint-2010.aspx

Improve this answer
1
  • We are using SP2010 and not using CLAIMS (we use NTLM). Is the 10 hours frequency still valid?
    – Mark L
    Jan 4, 2017 at 2:27
0

This problem in last month is a major threat for us and big mistake but these solutions impacts depend on your chance...

  1. hasn't any relation to UPS (user profile service) (dont waste your time for that)
  2. token timeout is a good solution in many cases in delays on apply change in 2010 or 2013 but major reason may in number 3
$sts = Get-SPSecurityTokenServiceConfig

$sts.WindowsTokenLifetime = New-TimeSpan -seconds 300

$sts.Update()

$sts = Get-SPSecurityTokenServiceConfig

$sts.LogonTokenCacheExpirationWindow = New-TimeSpan -Minutes 10

$sts.Update()
  1. Create an Organization Unit (OU) in the Active Directory (AD) and delegate Full Control rights to SharePoint Service Account (Central Administration Application Pool Account) source : here and here

if your users and groups all in one OU (organizational unit) and sharepoint admin account is diffrent from domain admins this solution in this link is only one solution/way for your problem.

this means sharepoint service account couldnt possible to access to user/groups information and their new membership so sharepoint has no permission to access to your new updates but for your new users applied before first login to sharepoint.

Why SharePoint 2010 or sharepoint2013 Check Permissions Can Give Wrong Results for AD Groups in this article also we have this problem

deligation in active directory grant permission to sharepoint user on OU organizational unit

Improve this answer
2
  • please delegate to all OUs that may users exist there or groups exist there (if you have many OU in root of your tree
    – saber tabatabaee yazdi
    Dec 5, 2016 at 19:41
  • if your admin account in sharepoint and active directory the same you dont have this problem
    – saber tabatabaee yazdi
    Dec 5, 2016 at 19:57
0

Another way of doing this is by using the STSADM executable that is available on the SharePoint server. Please note, that while this works in 2007, 2010 & 2013, it is deprecated in 2010 and 2013.

Set token timeout to 2 minutes : 

stsadm.exe -o setproperty -propertyname token-timeout -propertyvalue 2

Return to default setting (24 hours) :

stsadm.exe -o setproperty -propertyname token-timeout -propertyvalue 1440
Improve this answer

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.