Description
This article describes how to troubleshoot authentication failures due to 'clock skew' SAML errors.
Scope
FortiGate v7.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 [847]: Clock skew tolerance: 15
__samld_sp_login_resp [852]: Clock skew issue.
samld_send_common_reply [91]: Code: 5, id: 32255, pid: 301, len: 53, data_len 37
samld_send_common_reply [99]: Attr: 22, 12,
samld_send_common_reply [99]: Attr: 23, 25, Undefined error.
samld_send_common_reply [119]: Sent resp: 53, pid=301, job_id=32255.
samld_process_request [145]: len=11947, cmd=2, pid=304, job_id=32255
samld_process_request [162]: Received 11947, 0xcb3270
Here the FortiGate can be a few minutes away from the response time. The response time of SAML can be viewed in the 'IssueInstant' field in 'SP Login Response Msg Body' which is counted as reply time for SP.
-
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 are Manual which can also cause clock sync issues between FortiGate and IDP. Make changes in system settings: Set Time -> NTP, Select server -> FortiGuard.
By issuing the command, diag sys ntp status we can check if the NTP server is reachable from the FortiGate.
diag sys ntp status
synchronized: no, ntpsync: enabled, server-mode: disabled
ipv4 server(ntp1.fortiguard.com) 208.91.112.63 -- unreachable(0x0) S:7 T:1015
no data
ipv4 server(ntp2.fortiguard.com) 208.91.112.60 -- unreachable(0x0) S:7 T:1015
no data
If this is the case, under System -> Settings, try setting the time to manual, apply the change, and set it back to NTP:
diag sys ntp status
synchronized: no, ntpsync: enabled, server-mode: disabled
ipv4 server(ntp1.fortiguard.com) 208.91.112.63 -- reachable(0xff) S:0 T:7
no data
ipv4 server(ntp2.fortiguard.com) 208.91.112.62 -- reachable(0xff) S:0 T:7
no data
Related article:
Technical Tip: Troubleshoot NTP synchronization issue
