ADFS and SharePoint 2013: Re-authenticating every 4 minutes

Question

We have our token to expire after 10 hours, but every 4-5 minutes SharePoint goes out and re-authenticates against the token. Browser activity doesn't matter. How do we keep SharePoint from re-authenticating against the token? I feel like this has something to do with the FedAuth cookie, but not sure.

Answer 1

Enable STS Session Cookie

$sts = Get-SPSecurityTokenServiceConfig
$sts.UseSessionCookies = $true
$sts.Update()

LogonTokenCacheExpirationWindow for the SharePoint STS is 10 minutes. The relying party by default it sets the token lifetime in ADFS to be 2 minutes.

LogonTokenCacheExpirationWindow in SharePoint

$sts = Get-SPSecurityTokenServiceConfig
$sts.LogonTokenCacheExpirationWindow = (New-TimeSpan –minutes 1)
$sts.Update()

Then do an IISRESET

Answer 2

Set the ADFS value to high number like 10 hrs and set the sharepoint token expiration cache to lower value 20min(not 10 hrs) .

ADFS Sliding Expiration

SharePoint 2013 ADFS login local token cache always expired

Answer 3

Have you seen this?

https://social.technet.microsoft.com/Forums/en-US/954bf5e8-0a32-485d-97e0-7b842e315edc/fedauth-cookie-expiration-adfs-in-sharepoint-2010?forum=sharepointadminprevious

SharePoint calculates the expiration of the cookie with the following formula:

SAML Token Lifetime – Logon Token Cache Expiration Window

This forum post suggests to do this:

Run this command on ADFS, then start/stop ADFS after this is ran (not restart) (looks like this is already set correctly based on your screenshot in one of the comments above)

Add-PSSnapin Microsoft.ADFS.PowerShell  
Set-AdfsRelyingPartyTrust –TargetName "[ourrelayingpartytrustreference]" –TokenLifeTime 10

Run on sharepoint server:

$sts = Get-SPSecurityTokenServiceConfig
$sts.LogonTokenCacheExpirationWindow = (New-Timespan -Minutes 500)
$sts.Update()
iisreset

(I set it to 500 min here, but set it to however long you want it to be)

Did you try this yet? Hope this helps... sorry if it's just noise.

Answer 4

Don't know how helpful it will be, but we were also suffering from the same issue. Turns out it had nothing to do with the cache or token at all, but instead had to do with how many users could be cached per web front end. The default for SP 2013 is only 250 users, so as soon as user 251 logs in, it invalidates the cache for user 1. Then user 252 invalidates 2 and so on. In any decent sized organization this can lead to a round-robin of invalidation. We fixed with the following PowerShell script.

$maxTokens = 5000
$sts = Get-SPSecurityTokenServiceConfig
$sts.MaxServiceTokenCacheItems = $maxTokens
$sts.MaxLogonTokenCacheItems = $maxTokens
$sts.Update()
iisreset