To understand Single Sign-On (SSO) and Persistent Single Sign-On (PSSO) in Active Directory Federation Services (AD FS) you must first understand the authentication cookie. After the initial logon is validated an authentication cookie is written to the client (typically a browser). These cookies are implementation-specific and opaque to intermediaries and the user, including the federation service proxy for example. Subsequent authentication is done using the cookie and does not necessitate recapturing credentials or re-authenticating via the original means, e.g. forms-based or Kerberos/NTLM.
This is important. The cookie allows for subsequent authentication without recapturing credentials. In other words, the process is invisible or transparent to the user. The user is still authenticating, there’s still round trips back to the authentication service, but the user is not bothered – it’s seamless – it’s SSO.
Within the AD FS authentication and token issuance flow the FS writes the authentication cookie to the client as a session cookie by default. The cookie contains a signed token and a set of claims in-line with the claims issued by the Active Directory Domain Services (AD DS) Claims Provider trust (or any other CP in the federated scenario). Session cookies are bound to the session. When the parent process, i.e. the browser, is terminated the session is destroyed. Thus, regardless of the validity of the token, you kill all instances of your browser, for example, and the token is destroyed.
When a client requests a security token for a relying party (RP) from the FS the authentication cookie is used to authenticate to the FS and initialise or bootstrap the set of input claims for token issuance. This cookie provides SSO. An example being a client authenticates with AD FS and gets a token to an application, e.g. Azure AD, and then attempts to access another app, for example an on-premises federated app; the client already has a valid authentication token in the form of the cookie and therefore is able to SSO to the FS and obtain a new security token for the federated app.
Persistent Single Sign-On, or PSSO
PSSO is basically an authentication cookie that persists across sessions. By default, authentication cookies are session-based, which means when the browser closes the cookie is destroyed. PSSO cookies are written to Workplace Joined (WPJ)/registered devices by default, i.e. devices that have registered using Azure Device Registration Services (DRS) and been written back to the on-premises Active Directory Domain Services (AD DS) forest by Azure AD Connect (hybrid model); or registered directly using Windows Server 2012 R2 Device Registration Service (on-premises model).
AD FS will also set PSSO cookies if Keep Me Signed In (KMSI) is selected during the authentication process.
In addition, AD FS emits a PSSO claim type of http://schemas.microsoft.com/2014/03/psso with a value of “true”. The PSSO claim can be sent to Azure AD so that AAD and SharePoint Online honour the configuration too, i.e. AAD will issue PSSO cookies as a result of this being configured in AD FS. This is done by adding the following custom claim rule to the Azure AD (urn:federation:MicrosoftOnline) relying party trust:
psso:[Type == "http://schemas.microsoft.com/2014/03/psso"] => issue(claim = psso);
SSO (and PSSO) settings
The AD FS 2012 R2 settings for SSO and PSSO are as follows:
- SSO lifetime is 480 minutes (8 hours) – configurable at the global/AD FS level (SsoLifetime property)
- PSSO is enabled – global configuration (PersistentSsoEnabled)
- KMSI is disabled – global configuration (KmsiEnabled)
- PSSO lifetime for registered devices is 10,080 minutes (seven days) – global configuration (PersistentSsoLifetimeMins)
- PSSO lifetime for KMSI is 1,440 minutes (24 hours) – global configuration (KmsiLifetimeMins)
All of the above are global settings, read using Get-AdfsProperties and managed using Set-AdfsProperties.
What about the actual tokens issued?
- Token lifetime is 60 minutes (1 hour) – configurable at the Relying Party (RP) trust level (TokenLifetime)
The RP settings are read using Get-AdfsRelyingPartyTrust and managed using Set-AdfsRelyingPartyTrust. The default value, when read, is zero, which actually means 60, as the property expects the configured value in minutes.
There’s another RP-specific setting worth calling out too:
- AlwaysRequireAuthentication – when true (false by default) the SSO cookie is ignored and a credential capture is mandated
Important note
If you authenticate using IWA then the re-authentication (credential capture) is invisible – it’s SSO – so you won’t see much from a UX perspective, but you’ll have a fresh and valid 60-minute token.
Always Require Authentication is particularly useful if you require Multi-Factor Authentication (MFA) for a sensitive app. Regardless of SSO/PSSO state, if you mandate MFA and Always Require Authentication for an RP then each time you need a token for that app you will MFA.
Changes in Windows Server 2016
Active Directory Federation Services 2016 changes some of the above settings. There’s a new TechNet document describing the registered devices and non-registered devices SSO settings:
- AD FS 2016 Single Sign On Settings
https://technet.microsoft.com/en-us/library/mt728960.aspx
I’ll describe the information here for posterity purposes.
- Registered devices. By default, users with registered devices will get SSO for up to a maximum of 90 days if they use their device to access AD FS resources within a 14 day window. This behaviour is controlled by two new settings/values:
- Maximum SSO period (PersistentSsoLifetimeInMins – default value is 60,480)
- Device Usage Window (DeviceUsageWindowInDays – default value is 14)
- Non-registered devices. For non-registered devices SSO and PSSO is managed using KMSI settings, as is true of AD FS 2012 R2.
- If KMSI is disabled the SSO cookie has an 8-hour validity (SsoLifetime property of the RP trust).
- If KMSI is enabled the SSO cookie has a 24-hour validity (KmsiLifetimeMins – default value is 1,440; property is global; maximum upper value is 7 days)
Summary
AD FS 2012 R2 and AD FS 2016 tokens have a one hour (sixty minute) validity period by default. This value is configurable on a per-relying party trust basis. Token issuance requires that the token requestor has been authenticated by AD FS and has authorisation to request a token. When a user is authenticated by AD FS an authentication cookie is written to the client to provide an SSO period, and subsequent requests to AD FS utilise this SSO period (authentication cookie). The default value for the SSO period is 8 hours and is configurable at the global AD FS level. If Keep Me Signed In is enabled and selected by the requestor, the SSO lifetime increases to 24 hours by default. This value is configurable, globally, up to a maximum of 7 days. If the requestor is authenticating from a registered device the SSO lifetime increases to 7 days in AD FS 2012 R2 and 90 days in AD FS 2016. The 90 day validity requires an authentication within a 14 day period known as the device usage window, which means if you don’t access an AD FS application for more than 14 days then credentials will need to be recaptured, i.e. the SSO cookie is invalidated.
Lastly, you can configure a property of an RP trust to force authentication every time a token is requested. That is, by enabling Always Require Authentication you configure AD FS to ignore SSO cookies for the configured trust(s). This is useful when you want to deploy and utilise PSSO but need to mandate MFA for high-value assets.
