1

I have an AD group "superusers" which has direct access to some list items in a list. Using Check Permissions show that even though the AD group is listed with access to the list item, it does not have access. User in AD group can confirm this. See this screen shot of the issue: Check permissions for the AD group

If I remove permissions for the AD group and readd to the same item with same permission level it works again - confirmed by user in AD group. And "Check Permissions" show expected info: Check permissions for the AD group after readding

Can anyone explain this behavior and possible fix?

I have seen various people having an issue where users recently added to an AD group do not get access due to SharePoint caching of security token, however, this is not the issue here.

Improve this question
2
  • Does the access break by itself, say e.g. every morning, or do you have to do the re-adding of the permissions every time you for the first time assign permissions? What permissions does the AD group for the list where the items are?
    – moe
    Commented Oct 10, 2016 at 7:15
  • AD group has Full Control on list (and web). It seems the permissions disappear periodically but I have not found a pattern for that yet...
    – Kristian
    Commented Oct 10, 2016 at 7:20

1 Answer 1

Reset to default
0

Permissions for users are stored via a token, of which there are two types; security tokens and external tokens. Security tokens are generated each time a user logs into SharePoint. The external token is slightly more complicated, an external token is created when either an interactive or non-interactive authentication takes place. External tokens are cached for up-to 24 hours by default to overloading Active Directory (or whatever other identity provider is in use) so sometimes don’t reflect any recent changes in user memberships.

You can, however, change the default timeout settings as so;

$cs = [Microsoft.SharePoint.Administration.SPWebService]::ContentService

$cs.TokenTimeout = New-TimeSpan -Minutes 2

$cs.Update()

Source: MSDN

Hope this helps

Improve this answer
1
  • Hi George. Thanks for the answer and the explanation. As mentioned in my læast comment in the question, I don't think the cache of security token(s) can be the issue, as I can have one item showing correct result and another showing wrong result at the same time (the items have same permissions, e.g. the AD group is permitted to both). If SharePoint used a cached token, I would expect SharPoint to use it on both items, hence have the issue on both. Also the "fix" is removed after a certain time (pattern not found).
    – Kristian
    Commented Oct 11, 2016 at 7:45

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.