How to check if NTP is working on your RSA SecurID Access Identity Router

[#1]

Article Number

000035059

Applies To

RSA Product Set: RSA SecurID Access
RSA Product/Service Type: Identity Router
 

Issue

One of the items that should be configured on an Identity Router (IDR), is the address of an accessible Network Time Protocol (NTP) server to keep the IDR time accurate and synchronized with the rest of the deployment.   The NTP server is set for an IDR when you Configure Network Settings Using the Identity Router Setup Console.

Having accurate time is important for authentication session management and other purposes.

This article explains how to check if an IDR has been successfully connecting to an NTP server and adjusting its time accordingly.

 

Task

The IDR's NTP daemon, known as ntpd, runs once daily to connect to its configured NTP server and adjust the IDR's time, as necessary.

Runtime events for ntpd are logged in the /var/log/messages file.

To check if ntpd has been able to connect to the NTP server and adjust time successfully each day, check /var/log/messages and search for any events containing ntpd.  This must be done for every IDR, as follows:

1. Generate and Download an Identity Router Log Bundle.
2. Unzip the downloaded log bundle, and edit the file var\log\messages.  This is a text file so any text editor can be used, such as Microsoft Notepad.
3. Look for daily events that contain ntpdate and ntpd.

Resolution

A successful run of ntpd on an IDR will typically contain events such as the following in its /var/log/messages file (there may be some events from other components interleaved with these).  Note the events time stamped starting at Jan 28 16:15:11: one states that ntpd synchronized with a specific IP address, and the next one states there was a non-zero time slew.

Jan 28 16:15:02 portal ntpdate: Force synchronizing time
Jan 28 16:15:02 portal ntpd[27058]: ntpd exiting on signal 15
Jan 28 16:15:02 portal ntpd[27058]: can't open /var/lib/ntp/drift.TEMP: Permission denied
Jan 28 16:15:02 portal ntpdate: Shutting down network time protocol daemon (NTPD)..done
Jan 28 16:15:02 portal ntpd[13802]: ntpd 4.2.4p8@1.1612-o Mon Feb  9 13:31:58 UTC 2015 (1)
Jan 28 16:15:02 portal ntpd[13802]: precision = 1.000 usec
Jan 28 16:15:02 portal ntpd[13802]: ntp_io: estimated max descriptors: 1024, initial socket boundary: 16
Jan 28 16:15:02 portal ntpd[13802]: Listening on interface #0 wildcard, 0.0.0.0#123 Disabled
Jan 28 16:15:02 portal ntpd[13802]: Listening on interface #1 wildcard, ::#123 Disabled
Jan 28 16:15:02 portal ntpd[13802]: Listening on interface #2 eth0, fe80::250:56ff:fe9a:6435#123 Enabled
Jan 28 16:15:02 portal ntpd[13802]: Listening on interface #3 eth1, fe80::250:56ff:fe9a:7a90#123 Enabled
Jan 28 16:15:02 portal ntpd[13802]: Listening on interface #4 lo, ::1#123 Enabled
Jan 28 16:15:02 portal ntpd[13802]: Listening on interface #5 lo, 127.0.0.1#123 Enabled
Jan 28 16:15:02 portal ntpd[13802]: Listening on interface #6 lo, 127.0.0.2#123 Enabled
Jan 28 16:15:02 portal ntpd[13802]: Listening on interface #7 eth0, 10.156.194.12#123 Enabled
Jan 28 16:15:02 portal ntpd[13802]: Listening on interface #8 eth1, 10.156.194.11#123 Enabled
Jan 28 16:15:02 portal ntpd[13802]: Listening on interface #9 tun0, 10.250.242.26#123 Enabled
Jan 28 16:15:02 portal ntpd[13802]: kernel time sync status 2040
Jan 28 16:15:02 portal ntpd[13802]: Frequency format error in /var/lib/ntp/drift
Jan 28 16:15:11 portal ntpd[13802]: synchronized to 10.0.10.133, stratum 4
Jan 28 16:15:11 portal ntpd[13802]: time slew +0.000267 s
Jan 28 16:15:11 portal ntpdate: ntpd: time slew +0.000267s
Jan 28 16:15:11 portal ntpd[13874]: ntpd 4.2.4p8@1.1612-o Mon Feb  9 13:31:58 UTC 2015 (1)
Jan 28 16:15:11 portal ntpd[13875]: precision = 1.000 usec
Jan 28 16:15:11 portal ntpd[13875]: ntp_io: estimated max descriptors: 1024, initial socket boundary: 16
Jan 28 16:15:11 portal ntpd[13875]: Listening on interface #0 wildcard, 0.0.0.0#123 Disabled
Jan 28 16:15:11 portal ntpd[13875]: Listening on interface #1 wildcard, ::#123 Disabled
Jan 28 16:15:11 portal ntpd[13875]: Listening on interface #2 eth0, fe80::250:56ff:fe9a:6435#123 Enabled
Jan 28 16:15:11 portal ntpd[13875]: Listening on interface #3 eth1, fe80::250:56ff:fe9a:7a90#123 Enabled
Jan 28 16:15:11 portal ntpd[13875]: Listening on interface #4 lo, ::1#123 Enabled
Jan 28 16:15:11 portal ntpd[13875]: Listening on interface #5 lo, 127.0.0.1#123 Enabled
Jan 28 16:15:11 portal ntpd[13875]: Listening on interface #6 lo, 127.0.0.2#123 Enabled
Jan 28 16:15:11 portal ntpd[13875]: Listening on interface #7 eth0, 10.156.194.12#123 Enabled
Jan 28 16:15:11 portal ntpd[13875]: Listening on interface #8 eth1, 10.156.194.11#123 Enabled
Jan 28 16:15:11 portal ntpd[13875]: Listening on interface #9 tun0, 10.250.242.26#123 Enabled
Jan 28 16:15:11 portal ntpd[13875]: kernel time sync status 2040
Jan 28 16:15:11 portal ntpd[13875]: Frequency format error in /var/lib/ntp/drift
Jan 28 16:15:11 portal ntpdate: Starting network time protocol daemon (NTPD)..done
Jan 28 16:15:11 portal ntpdate: Time synchronized

If the NTP server time is incorrect or unstable you may see messages like the one below, rather than a valid non-zero "time slew" message:

Apr 30 18:45:14 portal ntpd[6049]: ntpd: no servers found

If the IDR has not been able to connect to the configured NTP server because the NTP server was not listed in the configured DNS, you will get something like the following example instead of the lines above.  Note that here, instead of a server IP address in the synchronized event, it shows that it synchronized with LOCAL(0) and time slew is always 0:

Jan 28 16:15:11 portal ntpd[13802]: synchronized to LOCAL(0), stratum 10
Jan 28 16:15:11 portal ntpd[13802]: time slew +0.000000 s

Notes

The stratum number reported by the NTP server in the synchronized event is an indication of how many NTP server hops there are between it and the reference clock.  A lower number means it is closer, and so the time the NTP server delivers is more accurate.