SharePoint 2013 Claim Expiration and AD Sync

Here’s an interesting scenario I hadn’t experienced before:  SharePoint 2013 farm doing a user profile sync with Active Directory. Security was based on Active Directory security groups managing membership and authorization controlled through SharePoint groups containing the AD groups. As users were added and removed to/from the AD groups, they weren’t seeing the change reflected in the SharePoint sites. After a crash course in claim caching, here’s what we ended up with.

First, an admittedly simplistic view of how SharePoint manages tokens:

  1. User browses to SharePoint site
  2. SharePoint checks local token store (STS) for a non-expired cached claim for that user
  3. If not found, STS creates a new claim by querying AD and then adds it to the cache
  4. If found, uses the cached claim

That covers the user, now lets look at how SharePoint syncs with AD to get group and membership info. Managed by the User Profile Sync service, SharePoint queries AD to learn about new or removed users as well as group membership. This is also controlled by a cache, and can create the scenario we ran into where AD users that were added or removed from AD groups did not have their authorization permissions updated in SharePoint.

By default, SharePoint will cache this group membership info for 24 hours. Well, we weren’t that patient. We changed it to two minutes using the following command:

stsadm.exe -o setproperty -propertyname token-timeout -propertyvalue 2

That sets the timeout to two (2) minutes. Admittedly a bit extreme, but we’ll set it back to a more reasonable timeframe when things aren’t so volatile.

So that takes care of SharePoint becoming aware of AD group permission changes, but how about user claims being updated? If SharePoint is aware of a user now being granted access through membership in an AD group, but that user obtained their claim earlier in the day before the AD group membership was changed, they will still be denied access. To change that we looked at setting the LogonTokenCacheExpirationWindow and WindowsTokenLifetime properties for the STS:

$sts = Get-SPSecurityTokenServiceConfig
$sts.FormsTokenLifetime = (New-TimeSpan -minutes 2)
$sts.WindowsTokenLifetime = (New-TimeSpan -minutes 2)
$sts.LogonTokenCacheExpirationWindow = (New-TimeSpan -minutes 1)
$sts.Update()
iisreset

The above is telling the STS that claims tokens are good for one (1) minute. WindowsTokenLifetime – LogonTokenCacheExpirationWindow, so 2 – 1 = 1. I’m pretty good with math. Default for both is 10 hours.

Oh, if you happen to set a lifetime that is shorter than the expiration window, that’s a good way to block users from accessing the site. Once their existing token expires, they’ll start seeing a message “The context has expired and can no longer be used.

image

In other words, don’t do that. Smile

Now every minute STS will refresh the claim token for a user to get the latest and greatest membership info from AD. That seemed to do the trick for this scenario, and we’ll definitely adjust the values above when things aren’t so volatile, but for now we’re looking good.

Here are a couple references we used to get to this result:
http://blog.amhawkins.com/2012/12/17/setting-the-sharepoint-2010-token-timeout-property/
http://blog.robgarrett.com/2013/05/06/sharepoint-authentication-and-session-management/ (specific to ADFS, but after being shown this through a co-worker I really started to understand lifetime and expiration dependencies)

For any security and/or IT Pro experts reading this, please comment and correct me where I’m wrong or was too vague.

12 thoughts on “SharePoint 2013 Claim Expiration and AD Sync”

  1. Matt says:

    Where are you running your scripts? The first one looks like stsadm but the second?

    I tried to run it in PowerShell and it doesn’t recognize any of those commands.

  2. Brian says:

    Here is how you can replace that stsadm command with PowerShell

    if((Get-PSSnapin -Name Microsoft.SharePoint.Powershell -ErrorAction SilentlyContinue) -eq $null)
    {
    Add-PSSnapin Microsoft.SharePoint.Powershell
    }

    $cs = [Microsoft.SharePoint.Administration.SPWebService]::ContentService
    $cs.TokenTimeout = (New-TimeSpan -minutes 2)
    $cs.Update()

    1. mina says:

      hi, i have a problem . i do not know where i should write those scripts.i have the same problem with this.where exactly shuold run these 🙁

  3. RM says:

    Hi thanks for a useful blogpost, I have a question as a newbie on powershell.
    Is there a way in powershell to just check the token time for my SP site?
    I just wanna check what the timer is set to on my SharePoint intranet.

    Over and out

    1. Look at the previous comment by Brian and check the value of $cs.TokenTimeout.

  4. mina says:

    i run “stsadm.exe -o setproperty -propertyname token-timeout -propertyvalue 2”
    in powershell but got errors:

    stsadm.exe : The term ‘stsadm.exe’ is not recognized as the name of a cmdlet, function, script file, or operable
    program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
    At line:1 char:1
    + stsadm.exe -o setproperty -propertyname token-timeout -propertyvalue 2
    + ~~~~~~~~~~
    + CategoryInfo : ObjectNotFound: (stsadm.exe:String) [], CommandNotFoundException
    + FullyQualifiedErrorId : CommandNotFoundException

    1. You need to run these commands in a SharePoint Powershell command window on the SharePoint app server.

  5. blumen says:

    I tried to run the command Brian provided and I got the “Content has expired error”. I have set the TokenTimeout as 120 minutes. Once the users got kicked out the site with the above error I set the TokenTimeout back to 24 hours and everything was working fine.

    I got this error on subsites in a site collection but not on the root site. This web application was claims but the site collection was in 2010 mode.

    Why does that happen, is SharePoint 2013 not issuing new tokens?

  6. Oliver Cortinas says:

    Hi, i have a doubt, i manage the access to a sharepoint site by groups, but when a change is made in the group, for example remove one persona from the group, this is not reflected after the sync profiles from AD and even after the user log-off log-on, i run this scripts and works to sync for new users on the group but the removed users still has access to the site and they are not belong any more to the AD group. Any ideas?

  7. Vinny says:

    The above is telling the STS that claims tokens are good for one (1) minute. WindowsTokenLifetime – LogonTokenCacheExpirationWindow, so 2 – 1 = 1. I’m pretty good with math. Default for both is 10 hours.

    I believe this is an incorrect statement, one is 10hours and one is 10mins

  8. Vijay says:

    We have an issue where AD groups were recreated, in this case we need to wait for 24 hours sharepoint app to work normal. We tried to change the token time out to 2 minutes. But this will apply only after 24 hours. Is there anyway to force reset the token time out value so that users no need to wait for 24 hours.

    Please advise on this, we have this problem couple of times where operations struck for a day in both cases.

    1. JB says:

      #set SharePoint token expiration to 2 minutes
      stsadm.exe -o setproperty -propertyname token-timeout -propertyvalue 2

      #set Forms/Windows token expiration
      $sts = Get-SPSecurityTokenServiceConfig
      $sts.FormsTokenLifetime = (New-TimeSpan -minutes 2)
      $sts.WindowsTokenLifetime = (New-TimeSpan -minutes 2)
      $sts.LogonTokenCacheExpirationWindow = (New-TimeSpan -minutes 1)
      $sts.Update()
      iisreset

      Run the block of statements above in SharePoint Management Shell. It includes an ‘iisreset’ command to force the changes to take effect. If you host other websites in IIS and can’t afford to reset it mid-day, omit that line and try manually restarting SharePoint services instead.

      Hope this helps.

Leave a Reply

Your email address will not be published. Required fields are marked *