SharePoint 2013 : use AD groups ? yes, but…don’t forget the Security Token caching: LogonTokenCacheExpirationWindow and WindowsTokenLifetime

One of the good practice in SharePoint Security is to organize users in centralized groups (like Active Directory groups) managed by the identity management service of the company and to nest these groups into SharePoint security groups. This approach provides easy security management

There are pros and cons of using only AD groups, but basically the usual pattern is :

  • in intranet/extranet : use AD Groups and nest them in SharePoint groups
  • in collaboration sites : play more with SharePoint groups and less with AD groups (=more flexibility in security management)

However, last week I noticed that SharePoint didn’t take my AD group modifications into account.

One of my AD user contoso\annab was part of an AD group called intranet members.

In my SP2013 intranet I had an Intranet members group (with the default edit permission level).

Everything worked perfectly…until I removed contoso\annaB from the member group. Even if she was not part of the group anymore, Annab was still able to contribute.

And as far as I remembered, SharePoint 2010 didn’t behave like this.

The reason is that by default SharePoint 2013 use claims based authentication. So we have to deal with claims.

By default when you create a web application in Central Administration, your web app is based on Claims. In my case, I was using Windows Claims sign-in; the AD group informations are converted into claims and packed into security token issued by the STS (Security Token Service)

The lifetime of tokens issued to logins that use Windows-based login is defined in the WindowsTokenLifetime property of the SecurityTokenServiceConfig (the default value is 10 hours)

The LogonTokenCacheExpirationWindow property (10 minute by default) of the SecurityTokenServiceConfig controls when SharePoint will consider that the security token has expired and awill ask the user to re-authenticate with the issuer and obtain a new token. SharePoint checks whether the Security token has expired at the start of every request.

for instance, if WindowsTokenLifetime = 10 minutes and  LogonTokenCacheExpirationWindow = 2 minutes

->this means that after 10 minutes-2 minutes = 8 minutes, SharePoint will decide that the security token has expired.

->If the user requests a page from SharePoint nine minutes after signing in, then SharePoint checks whether the session is set to expire during the time in minutes represented by LogonTokenCacheExpirationWindow: in this case the answer is yes because nine plus two is greater than ten.

Here are the default values :

image

The following Powershell script set the lifetime to 2 minutes (instead of 10 hours ) and the LogonTokenCacheExpirationWindows to 1 minute :

  • $mysts = Get-SPSecurityTokenServiceConfig
  • $mysts.WindowsTokenLifetime = (New-TimeSpan -Minutes 2)
  • $mysts.LogonTokenCacheExpirationWindow
  • $mysts.Update()

When the security token expires, the user is supposed to re-authenticate (Actually I didn’t noticed that, there is probably an NTLM re-negociation under the cover)

Make sure the LogonTokenCacheExpirationWindow is small than the WindowsTokenLifetTime, otherwise the authentication code will go back to AD to authenticate again. And so it goes, back and forth.

 

image

In order to make sure that AnnaB will be able to view the site, I’ve added her to Intranet Visitors :

 

image

When you click on Intranet members, you get the following AD group:

image

In this AG group, you will find AnnaB :

image

 

When I log into the site and go to a document library, indeed AnnaB has the required permissions to add documents :

image

 

Now, let’s remove AnnaB from the AD group :

image

AnnaB can still contribute :

image

But after 4 or 5  minutes (why not 2 minutes?, I don’t know yet) she can only read, which is what I expected.

image

 

So in summary you should always test your SharePoint intranet/extranet security settings by defining one or several virtual test users who can be moved to differents AD groups, but don’t forget to change the LogonTokenCacheExpirationWindow and the WindowsTokenLifetime . And be patient as usual.

In production the default values should be ok.

More links :

About these ads

One response to “SharePoint 2013 : use AD groups ? yes, but…don’t forget the Security Token caching: LogonTokenCacheExpirationWindow and WindowsTokenLifetime

  1. I’ve heard users complaining about issues like this in SharePoint 2010 (we removed the user from the group, but they can still edit!). Usually by the time I was able to troubleshoot the expiration had happened so I chalked it up to some sort of cache or expiration mechanism and never dug deeper. I didn’t know it was this (nor that it was configurable) until I read your post which in hindsight makes complete sense. Thank you!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s