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 the 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:
diagnose debug disable
diagnose debug reset
diagnose debug console timestamp enable
diagnose debug application samld -1
diagnose 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
Note: Stop the debugs with the following commands:
diagnose debug disable
diagnose debug reset
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 system process pidof ntpd
Or:
diagnose system top-all | grep ntpd
diagnose system kill 11 <pid> <-- Pid of the process.
To check if FortiGate is getting a response from NTP:
diagnose 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.
diagnose system 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:
diagnose system 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
In a few cases, FortiGuard NTP servers might not work with time sync even though the servers are reachable. In such a case, try with a custom server other than the FortiGuard server as shown in the example below.
config system ntp
set type custom
config netserver
edit 1
set server pool.ntp.org
end
end
Related article:
Technical Tip: Troubleshoot NTP synchronization issue
