When SharePoint 2013 authenticates a user, the Security Token Service creates a security token with the user’s identity and several other claims. This token is then added to the Distributed Logon Token Cache so that it can be checked later to confirm that the user is authenticated.

Create Security Token Service Application Sharepoint 2013 Powershell
Sharepoint 2013 Create Bcs Connection
Sharepoint Security Token Service

STS Security Token Service on SharePoint 2013 Today I was bringing my stepping server back up. In this case I use it to upgrade content databases from 2010 - 2016. SharePoint 2013 Distributed Cache Logon Token issue Distributed Cache Service (DCS) is a customized version of Windows App Fabric deployed in SharePoint 2013. The Distributed Cache service provides caching functionality to features (not to be confused with site features) in SharePoint Server 2013. The Security Token Service is Unavailable. Recent Comments. Provisioning a SharePoint 2013 or 2010 Farm SharePoint Service Applications.

When built, the token gets a lifetime that depends on the authentication provider used by the user to authenticate. For Windows and Forms (FBA) authentication, the lifetime is a fixed amount of time that is set on the Security Token Service configuration. For trusted providers like AD FS, the lifetime depends on the validity of the security token POSTed to SharePoint’s /_trust/ endpoint.

This lifetime has a direct impact in how often the user will need to authenticate. When the user makes a request, the token in the cache is checked and if it is expired, then the user needs to authenticate again.

As explained above, the lifetime can be configured in the STS for Windows and Forms authentication. The current values can be reviewed with Get-SPSecurityTokenServiceConfig.

WindowsTokenLifetime

This lifetime applies to user sessions authenticated with Windows Integrated Authentication (NTLM/Kerberos).
The default value is 10 hours.

$sts = Get-SPSecurityTokenServiceConfig
$sts.WindowsTokenLifetime = New-TimeSpan -Hours 10
$sts.Update()

FormsTokenLifetime

The same as above but applies to Forms/FBA authentication sessions.
The default value is also 10 hours.

$sts = Get-SPSecurityTokenServiceConfig
$sts.FormsTokenLifetime = New-TimeSpan -Hours 10
$sts.Update()

LogonTokenCacheExpirationWindow

The lifetime of a token in the cache is deducted the window value when checking if it is expired. This means that the real lifetime of the token will be less than expected. The following diagram can be helpful to understand when a token is valid and the roles the lifetime and window play in the expiration.

The default value for the expiration window is 10 minutes.

$sts = Get-SPSecurityTokenServiceConfig
$sts.LogonTokenCacheExpirationWindow = New-TimeSpan -Minutes 10
$sts.Update()

CookieLifetime

When using FBA or a trusted provider, SharePoint will set a cookie on the client called FedAuth. I’ll not go into the details of what’s inside the FedAuth cookie. Of course, the FedAuth cookie will have by default a certain lifetime. Session cookies can be configured too making the cookie invalid after the closing the browser and then bypassing the value in this settings.

The default value is 5 days.

$sts = Get-SPSecurityTokenServiceConfig
$sts.CookieLifetime = New-TimeSpan -Minutes 15
$sts.Update()

So, if we are using a trusted provider, for example, AD FS, how do we control how long the token will be valid? It will depend on how you can configure the STS that creates the token but if it is AD FS then you can set this in the Relying Party configuration.

ADFS RP’s TokenLifetime

This setting will change for how long the security token created by AD FS is valid. SharePoint will use this lifetime and set its security token lifetime to the same value.

The default value is 60 minutes (which appears as 0 if the setting has not been changed in the RP). Security Token Service In Sharepoint 2013

Security Token Service In Sharepoint 2013

You can check the current settings with:

Get-AdfsRelyingPartyTrust | ft -auto Name,TokenLifetime

And to change the value for a RP:

Set-AdfsRelyingPartyTrust -TargetName “SharePoint 2013” -TokenLifetime 30

These are the main settings related to session lifetimes when dealing with user authentication. There are other values for applications and services but are kind of exotic and you won’t usually need to change those.

There is one extra setting that is interesting to have in mind although it does not affect the authentication of a user.

Token-timeout

SharePoint stores in the content database a token of the user that includes some claims like group memberships. This token needs to be refreshed from time to time to make features like “Check permissions” and other some security trimmed features work as expected.

Create Security Token Service Application Sharepoint 2013 Powershell

These tokens will be refreshed at least every 24 hours. Some operations that require having a fresher token, like “Check permissions”, will refresh the token at least every 60 minutes.

TokenTimeout will change the default 24 hours timeout to a greater or smaller amount. If the value is still greater than 60 minutes, some operations will still use 60 minutes as minimum.

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

Reference :

Link 1

Many of us have experienced errors when starting SharePoint 2013 Designer for Workflows. One of the most common errors is:

“Retrying last request. Next attempt scheduled in less than one minute. Details of last request: HTTP Unauthorized to /_vti_bin/client.svc/SP.WorkflowServices.InteropService.Current/StartWorkflow Correlation Id: abeacd31-09ba-4a4e-8fdf-79eb7af480fe Instance Id: 9c909563-00c1-4b66-b3b4-d48c6da06b22”

In starting to troubleshoot, you will see messages like the following in the ULS Log files:

Entering monitored scope (Getting Site Subscription Id). Parent [Marketplace] Getting token from STS and setting Thread Identity
SecurityTokenServiceSendRequest: RemoteAddress: ‘http://###/SecurityTokenServiceApplication/securitytoken.svc’ Channel: ‘Microsoft.IdentityModel.Protocols.WSTrust.IWSTrustChannelContract’ Action: ‘http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/Issue’
SPJsonWebSecurityBaseTokenHandler: ValidateActorIsSelfIssuer! Issuer ‘00000005-0000-0000-c000-000000000000’ is not self issuer.