WARNING: NTP synchronization failed.

Document ID : KB000047644
Last Modified Date : 14/02/2018
Show Technical Document Details


I'm trying to register a *nix endpoint to my Active Directory Domain Controller and I'm receiving an error, explaining about how the NTP synchronization failed.
WARNING: NTP synchronization failed. 
/opt/CA/uxauth/bin/uxconsole -register -a administrative_account_here -w administrative_account_password_here -d the_targeted_domain_controller  



This is for any UNAB solution on any release of any *nix OS.



NTP timestamps are stored as seconds since January 1, 1900. 32 bits for the number of seconds, and 32 bits for the fractions of a second.


The synchronization is tricky. The client stores the timestamp (say A) (all these values are in seconds) when it sends the request. The server sends a reply consisting of the "true" time when it received the packet (call that X) and the "true" time it will transmit the packet (Y). The client will receive that packet and log the time when it received it (B).


NTP assumes that the time spent on the network is the same for sending and receiving. Over enough intervals over sane networks, it should average out to be so. We know that the total transit time from sending the request to receiving the response was B-A seconds. We want to remove the time that the server spent processing the request (Y-X), leaving only the network traversal time, so that's B-A-(Y-X). Since we're assuming the network traversal time is symmetric, the amount of time it took the response to get from the server to the client is [B-A-(Y-X)]/2. So we know that the server sent its response at time Y, and it took us [B-A-(Y-X)]/2 seconds for that response to get to us.


So the true time when we received the response is Y+[B-A-(Y-X)]/2 seconds. And that's how NTP works.


Example (in whole seconds to make the math easy):


  1. Client sends request at "wrong" time 100. A=100.
  2. Server receives request at "true" time 150. X=150.
  3. The server is slow, so it doesn't send out the response until "true" time 160. Y=160.
  4. The client receives the request at "wrong" time 120. B=120.
  5. Client determines the time spend on the network is B-A-(Y-X)=120-100-(160-150)=10 seconds
  6. Client assumes the amount of time it took for the response to get from the server to the client is 10/2=5 seconds.
  7. Client adds that time to the "true" time when the server sent the response to estimate that it received the response at "true" time 165 seconds.
  8. Client now knows that it needs to add 45 seconds to its clock.
  9. In a proper implementation, the client runs as a daemon, all the time. Over a long period of time with many samples, NTP can actually determine if the computer's clock is slow or fast, and automatically adjust it accordingly, allowing it to keep reasonably good time even if it is later disconnected from the network. Together with averaging the responses from the server, and application of more complicated thinking, you can get incredibly accurate times.




Stopped UNAB:

/opt/CA/uxauth/lbin/uxauthd.sh stop 


Made sure the uxconsole utility recognized that uxauthd was down: 

/opt/CA/uxauth/bin/uxconsole -status -detail 


Ensured that the OS saw there was no uxauthd service running: 

ps -ef | grep uxauthd 


Go into your uxauth.ini and appended as the following: 

use_time_sync = no 


If you want to use the NTP server's time synchronization, then ensure the NTP server is correct and also we set the interval appropriately.

ntp_server = server_goes_here

time_sync_interval = 3600 


/opt/CA/uxauth/lbin/uxauthd.sh start 


Try re-registering the endpoint like we did originally and the NTP exception will disappear, allowing you to fulfill the registration.