This post will try to explain some relevant parameters from the ADFS side. I’m not saying the defaults aren’t good, that’s something you’ve got to decide for yourself.


WS-Fed/SAML protocol requirements: All time is UTC. ADFS will ignore system time and will use UTC.

Dates in SAML

A Security Assertion Markup Language(SAML) assertion might contain many attributes that contain dates. For example the following Conditions element of a SAML assertion has two date attributes:
<saml:Conditions NotOnOrAfter=”2013-07-29T23:49:40.051Z” NotBefore=”2013-07-29T23:39:40.051Z”>

Time in SAML elements is expressed in xs:dateTime format (xs is a XML format style). The Z at the end indicates that the Time Zone is Coordinated Universal Time (UTC) or Zulu time format. SAMLCore explicitly references “W3C XML Schema Datatypes specification [Schema2]” which in turn references ISO 8601.

Dates in OpenTokens

An OpenToken contains multiple dates. For example the following OpenToken contains three dates:


The format for OpenTokens also uses ISO 8601 which also uses UTC.
See also: Microsoft KB 884804 – How to convert UTC time to local time

WebSSOLifetime (Default 480 = 8 hours)

This parameter is server-wide. Meaning if you configure it, it’s active for all of the ADFS relying parties. Whenever a user asks a token for a given RP he will have to authenticate to the ADFS service first. Upon communicating with the ADFS service he will receive two tokens: a token which proves who he is (let’s call that the ADFS Token) and a token for the RP (let’s say the RP Token). All in all this seems very much like the TGT and TGS tickets of Kerberos.

Now the WebSSOLifetime timeout determines how long the ADFS token can be used to request new RP Tokens without having to re-authenticate. In other words a user can ask new tokens for this RP, or for other RP’s, and he will not have to prove who he is until the WebSSOLifetime expires the ADFS token.

TokenLifetime (Default 0 (which is 10 hours))

The TokeLifetime is now easy to explain. This parameter is configurable for each RP. Whenever a user receives a RP Token, it will expire at some time. At that time the user will have to go to the ADFS server again an request a new RP token. Depending on whether or not the ADFS Token is still valid or not, he will not have to re-authenticate.

One argument to lower the TokenLifetime could be that you want the claims to be updated faster. With the default whenever some of the Attribute Store info is modified, it might potentially take 10 hours before this change reaches the user in its claims.

NotBefore and NotOnOrAfter, NotBeforeSkew

Setting up federated trusts with third-party vendors to provide users with single sign on (SSO) is very common.  SAML2 is the preferred method for SSO authentication.  One issue with this method is ensuring the SAML tokens have a valid lifespan.  Basically, when does a token become valid and when is it no longer valid.  Built into the SAML specification, there is a <saml:Conditions> element, which contains two attributes; NotBefore and NotOnOrAfter.  The NotBefore attribute contains the date and time value that specifies when the assertion becomes valid.  The NotOnOrAfter attribute contains the date and time value that specifies when the SAML assertion is no longer valid.  Both must be UTC datetimes, without the time zone.  As long as the SAML token is being used between the NotBefore and NotOnOrAfter times the assertion will be valid.

But what happens when the IdP server time and the third-party server times are off by a few seconds, or even a couple of minutes?  Simple, authentication may fail because the third-party server may see the SAML as not yet valid.

Luckily, ADFS 3 (Windows Server 2012 R2) offers a simple solution.  A simple time skew value can be added to the relying party on the ADFS server.  This property is called NotBeforeSkew.  It contains the number of minutes to adjust the NotBefore value by.  Setting the NotBeforeSkew to a value of 5 will result in a NotBefore of -5 minutes.

The following PowerShell command can be used to set the NotBeforeSkew value.

Set-ADFSRelyingPartyTrust -TargetIdentifier "<replying party identifier>" -NotBeforeSkew 5