UltraNote: AD FS SSL VPN Clock Skew

In assisting a customer with the AD FS configuration we encountered some difficulties in redirection. The particular issue looked like this:

1. User would would type in the SSL VPN URL

2. User would be redirected to AD FS

3. User would authenticate with AD FS

4. The web page would pause forever on a blank screen

5. It would finally redirect to fortigate.sslvpn.url/remote/saml/login/ and give an error

We ran the following debugs:

diagnose debug console timestamp enable
diagnose debug application samld -1
diagnose debug enable

And re-ran the process above. In the final step of the SAML we noticed that the output gave us the following error:

__samld_sp_login_resp [859]: Clock skew tolerance: 0

__samld_sp_login_resp [864]: Clock skew issue.
samld_send_common_reply [114]: Code: 4, id: 11756, data_len: 45
samld_send_common_reply [122]:     Attr: 21, 8,
samld_send_common_reply [122]:     Attr: 22, 21, Undefined error.

This told me there was something going on with the time on or or the other systems. I pulled up the dashboard of the FortiGate and compared it with the System Clock of the AD FS server, and the FortiGate was about 20 seconds behind the AD FS server.

The "conditions" attribute in the SAML Assertion that looks like this:

<Conditions NotBefore="2022-03-02T19:28:37.644Z"...></condititions>

Which basically tells the FortiGate "Not good before X time". So in essence the FortiGate was receiving a request for a time that had not occurred yet, and the request asserts that it's not good before the timestamp.

First thing I did was force an NTP update on the FortiGate, and it seemed to have an issue still - the time was within a second or two, but didn't seem to be enough. The next step I took was to update the SAML IdP configuration on the FortiGate to allow for some clock skew:

config user saml
  edit vpn.ultraviolet.network
    set clock-tolerance 120
  next
end

That gave the FortiGate the ability to allow for 2 minutes of clock skew, which seemed to clear things up. Although the clock appeared to drift yet again, and we realized it may be an issue with AD FS not allowing for any clock skew. So we added 2 minutes of clock skew on AD FS as well. In PowerShell execute the following command:

Add-PSSnapin Microsoft.Adfs.PowerShell
  Get-ADFSRelyingPartyTrust –identifier "vpn.ultraviolet.network"
  Set-ADFSRelyingPartyTrust –TargetIdentifier "vpn.ultraviolet.network"  –NotBeforeSkew 1

And this seems to have cleared up the issue permanently.

One thing to note, the less clock skew you allow for, the better. It's generally not good practice to be loose with clock skew, and if all devices can be synchronized using NTP it's generally regarded as the best approach to this. There are situations however, like this one, where that is not possible. The hostnames above are representations of a real world scenario that we helped solve.

Thank you for reading, I hope this helps.