Working with a client recently I’d run across something that seemed pretty fundamental and widely-known (or so I thought); however, I’ve been wrong before and here was another example of exactly that.
As you may be aware, Microsoft has long recommended using Active Directory Groups to manage permissions in SharePoint. Though it’s a farily technical discussion, this MSDN blog post by Kirk Evans well demonstrates why this model is beneficial specifically regarding the impact on crawls by the Search Service.
However, using Active Directory Groups in SharePoint groups does introduce a particular behaviour that must be kept in mind. Consider the following scenario:
- A SharePoint site has permissions configured such that Active Directory Groups are members of the SharePoint groups
- You want to grant access to this site for a particular user, but that user is not a member of any of the Active Directory Groups
- You make the user a member of the Active Directory Group, using “Active Directory Users and Computers” on a Domain Controller
- The user is not able to access the SharePoint site.
- Further complicating matters, other users that were members of the Active Directory Group are able to access the site.
Why does this happen? It’s somewhat complicated, but it comes down to Domain Access Tokens and Security Token Caching.
Domain Access Tokens
Let’s start with the Active Directory side of things – a users Active Directory group membership is updated only when logging into the domain. This is descried in detail in this Technet article Active Directory Users, Computers, and Groups. You’ll notice that article is from the old days, when Active Directory was just introduced with Windows 2000. Here’s the relevant text, from the “Concepts” section of that article:
An access token is not updated until the next logon, which means that if you add a user to a group, the user must log off and log on before the access token is updated.
So the first thing that is preventing access to the site is the Domain Access Token – the user must log off and then back onto the domain before new AD Group membership is contained in their Access Token.
Security Token Caching
The second thing preventing the user from accessing the site is caching of the security tokens in SharePoint itself. Specifically the Security Token Service which caches the Windows Claim (token), and this cache is set to 10 hours by default. For a more in-depth example of this particular cache behaviour, please see SharePoint MVP Serge Luca’s post on the security token caching.
Our options in dealing with this are somewhat limited:
- adjust the cache values downwards
- perform an IISRESET on the SharePoint servers clearing the cached tokens
- be patient
In most scenarios the default value for this particular cache is going to be OK, and certainly adjusting it may have an impact on logging into SharePoint – proceed with caution. Performing IISRESET on production systems isn’t an option just to remedy user access issues that will resolve themselves with a little patience.
Placing Active Directory Groups into SharePoint groups is a recommended security model, but it’s not without its drawbacks and gotchas. User access tokens are only updated at logon time, necessitating a log off/log on to the domain to be updated. SharePoint caches security tokens for a while, so you either need to plan for this when migrating users, or be patient until the cache expires.
Since Domain Group membership does not change too frequently for most users, this particular scenario probably won’t be an issue when working with SharePoint day-to-day. But in cases where users are changing roles or you’re modifying the SharePoint security model this will cause you some grief. As a quick work-around in a time-sensitive situation you can always grant the user access by placing them into the SharePoint group directly, understanding that this does come with an impact to Search Crawl activity. Lastly, keep in mind that the same holds true when a user is removed from an Active Directory Group – the cached access tokens will continue allowing access to SharePoint resources until they expire.