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

Follow @sergeluca

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 :

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.

 

 

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

 

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

In this AG group, you will find AnnaB :

 

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

 

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

AnnaB can still contribute :

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

 

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.

Follow @sergeluca

More links :

• http://technet.microsoft.com/en-us/library/ff607549.aspx
• http://technet.microsoft.com/en-us/library/ff607642.aspx
• http://msdn.microsoft.com/en-us/library/hh446526.aspx
• http://blog.petercarson.ca/Pages/SharePoint-2010-Session-Management.aspx
• http://www.slideshare.net/technetbelux/265-room5-danholme