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