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.
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.
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()
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()
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()
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.
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).
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.
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.
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()
Link 1
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).
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.
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
No comments:
Post a Comment