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

Document created by RSA Customer Support Employee on Apr 20, 2017•Last modified by RSA Customer Support on May 26, 2018
Version 3Show Document
  • Comment • 0
  • View in full screen mode

Article Content

Article Number000035059
Applies ToRSA Product Set: RSA SecurID Access
RSA Product/Service Type: Identity Router
 
IssueOne 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.

 
TasksThe 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.
ResolutionA 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 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.

Attachments

    Outcomes