It’s not happening only on SharePoint 2013. You will be in the same situation if you are using Claims Based Authentication with SharePoint 2010.
Out of the box behavior
You have a SharePoint Web Application configured to use Claims Based Authentication. You grant access to a SharePoint site through Active Directory Security Groups. You perform changes in the membership of that Active Directory Security Group and you notice the changes are not reflected immediately on the SharePoint site.
For example you remove one user account from the AD security group membership, but the user is still able to access the site, or you add a new user to the membership of that security group, but the user still receives access denied on SharePoint.
SharePoint Claims Based Authentication is working differently than SharePoint Classic Mode Authentication. When you have Claims Based Authentication, SharePoint is using the Security Token Service (STS) to provide access tokens for server-to-server authentication.
The Wikipedia explanation for STS:
“A Security Token Service (STS) is a software based identity provider responsible for issuing security tokens, especially software tokens, as part of a claims-based identity system.
In a typical usage scenario, a client requests access to a secure software application, often called a relying party. Instead of the application authenticating the client, the client is redirected to an STS. The STS authenticates the client and issues a security token. Finally, the client is redirected back to the relying party and present the security token. The token is the data record in which claims are packed, and is protected from manipulation with strong cryptography. The software application verifies that the token originated from an STS trusted by it, and then makes authorization decisions accordingly. The token is creating a chain of trust between the STS and the software application consuming the claims. This process is illustrated in the Security Assertion Markup Language (SAML) use case, demonstrating how single sign-on can be used to access web services.”
So, in our case:
- a claims based SharePoint web application handle requests to issue, manage, and validate security tokens.
- the security tokens are a collection of identity claims (a user name, a role, an identifier).
- the security tokens can be protected with an X.509 certificate to protect the token’s contents in transit and to enable validation of trusted issuers.
- the SharePoint Security Token Service plays an important role for the claims based SharePoint web application.
The tokens have a lifetime (by default 10 hours). More than that, SharePoint by default will cache the AD security group membership details for 24 hours. That means, once the SharePoint will get the details for a security group, if the AD security group will change, SharePoint will still use the cache.
When your access in SharePoint rely on the AD security groups you have to adjust the caching mechanism for the tokens and you have to adjust it properly everywhere (SharePoint and STS).
Add-PSSnapin Microsoft.SharePoint.PowerShell; $CS = [Microsoft.SharePoint.Administration.SPWebService]::ContentService; #TokenTimeout value before $CS.TokenTimeout; $CS.TokenTimeout = (New-TimeSpan -minutes 2); #TokenTimeout value after $CS.TokenTimeout; $CS.update(); $STSC = Get-SPSecurityTokenServiceConfig #WindowsTokenLifetime value before $STSC.WindowsTokenLifetime; $STSC.WindowsTokenLifetime = (New-TimeSpan -minutes 2); #WindowsTokenLifetime value after $STSC.WindowsTokenLifetime; #FormsTokenLifetime value before $STSC.FormsTokenLifetime; $STSC.FormsTokenLifetime = (New-TimeSpan -minutes 2); #FormsTokenLifetime value after $STSC.FormsTokenLifetime; #LogonTokenCacheExpirationWindow value before $STSC.LogonTokenCacheExpirationWindow; #DO NOT SET LogonTokenCacheExpirationWindow LARGER THAN WindowsTokenLifetime $STSC.LogonTokenCacheExpirationWindow = (New-TimeSpan -minutes 1); #LogonTokenCacheExpirationWindow value after $STSC.LogonTokenCacheExpirationWindow; $STSC.Update(); IISRESET