Description
This article describes how to troubleshoot authentication failures due to 'clock skew' SAML errors.
Scope
FortiOS 7.0.4 and later.
Solution
- The SAML Assertion from SAML IDP is only valid for a specific duration which is declared in the 'Assertion'.
If the clock on FortiGate and SAML IDP is not in sync, then this constraint will not be satisfied which causes the authentication to fail with the below errors in SAML debugs:
diag de dis
diag deb reset
diag debug console timestamp en
diagnose debug application samld -1
diag debug enable
__samld_sp_login_resp [859]: Clock skew tolerance: 0
__samld_sp_login_resp [864]: Clock skew issue.
-
To fix this issue, make sure the time is in sync between FortiGate and the IDP.
-
In some cases, where the time sync between the FortiGate and IDP can not be controlled, 'clock-tolerance' can be configured to control how many seconds can be the difference between SP (FortiGate) and IDP as below:
config user saml
edit <>
set clock-tolerance <in seconds> <-- (0-300, 15 by default).
next
end
- Verify the connection to the NTP server as well. Restart the NTP process and ensure FortiGate is in sync with the NTP server.To restart the NTP process:
diagnose sys process pidof ntpd
Or:
diag sys top-all | grep ntpd
diag sys kill 11 <pid> <-- Pid of the process.
To check if FortiGate is getting a response from NTP:
diag sniffer packet any "port 123" 4 0 l
In certain cases where the DIA route is via an IPsec tunnel or FortiGate is behind a NAT device, it is mandatory to define the source IP address under the NTP configuration. This could be an outgoing interface IP, SNAT IP, or an IP allowed by the ISP.
config system ntp
set source-ip x.x.x.x
end
In some cases system settings for time is Manual which can also cause clock sync issue between FortiGate and IDP.
Make change in system settings: Set Time -> NTP, Select server -> FortiGuard.
Related article:
Technical Tip: Troubleshoot NTP synchronization issue
