[ntp:questions] Re: Questions and ruminations regarding NTPD 4 config and XP's bad behavior.

Richard B. Gilbert rgilbert88 at comcast.net
Fri Jan 14 17:18:44 UTC 2005


elickd at one.net wrote:

>I've been researching odd time sync. behavior beween a large group of
>SCO servers I administer and our internal NTP servers they sync. with.
>For reasons beyond my control, said SCO servers run a script at regular
>intervals (though not frequent enough for my taste) that calls ntpdate;
>they are not running ntpd.
>
>My poking and proding has revealed that there is a VERY large number of
>XP boxes on our network behaving exactly as Dr. Mills warned they
>would, should the NTP servers they query be misconfigured. "ntpq -p"
>run on one of our stratum 3 servers reports over 5 pages of such XP
>machines as valid stratum 4 time sources.
>
>In this anonymized version of our (stratum 3) NTP server config.
>(Linux, NTP 4.1.0), you can see that authentication has been disabled:
>-----------------------------------------------------------------
>server	127.127.1.0
>fudge 127.127.1.0 stratum 10
>
>server [Internal Stratum 2 Server #1] (Shouldn't we be peering
>server [Internal Stratum 2 Server #2]  with our stratum 2 servers?)
>
>  
>
I don't believe you can have a symmetric association (peering) between 
asymmetric strata.  Stratum two can peer with stratum two but not with 
one or three.

>#peer [ntp1]	# NTP1 <---<This server>
>peer [ntp2]	# NTP2
>peer [ntp3]	# NTP3
>peer [ntp4]	# NTP4
>
>driftfile /etc/ntp.drift
>multicastclient
>broadcastdelay	0.008
>
>authenticate no
>-----------------------------------------------------------------
>
>The above file is identical across all our stratum 3 servers except for
>which peers are commented out.
>
>Though it's been a long time since I've messed with NTP, it's my
>understanding that only one of the servers in a given stratum should
>have the clock fudge; in our case they *ALL* are kludged to stratum 10.
>  
>
I don't think that's wise.

>
>I also understand that having only two stratum 2 servers is a
>nonpreferred configuration, having peers in the same stratum reference
>eachother (especially with the clock fudge) can lead to wierd
>instabilities and leaving authentication off will allow the droves of
>rowdy XP machines in our network to be considered valid by the
>aforementioned NTP servers. Though I don't have direct access, I
>believe our two stratum 2 servers only point to the same two stratum 1
>servers each; this is quite sub-optimal.
>
>  
>
XP machines at stratum four should not be able to affect servers at 
stratum two or three!  NTP is hierarchical.    Each client will take 
time from the lowest stratum server available.

>Am I correct in my assertions? Setting authenticate to "yes" should
>"kick out" our uncivilized XP boxes, correct?  Or will I have to have
>"restrict notrust" entries added to our config files?  Bear in mind,
>the smallest configuration change possible is the most desireable,
>considering I have no authority to change them and must persuade the
>admin. of those machines to agree.
>  
>
There is more to authentication than setting authentication to "yes".   
For authentication to work, server and client must share a set of 
cryptographic keys and methods.  There are several ways authentication 
can be set up and I believe that all of them require the cooperation of 
the administrators of the client and the server.  In some cases the 
administrator of a server may have automated the process so that you can 
simply use e-mail or visit a web site to request a client key.

>The following are my (slighly misformatted) notes when running ntpdate
>(SCO) against my XP laptop; here are the interesting results:
>
>-------------------------------------------------------------------Ran
>ntpdate -qd against my WinXP laptop. Interestingly, even though I had
>synchronized the previous day, the reference time reported is bogus.
>The date is Feb 7, 2036!
>-------------------------------------------------------------------
>
>root at xxxxx / # ntpdate -q 10.251.23.144
>server 10.251.23.144, stratum 16, offset 0.087654, delay 0.04124
>14 Jan 08:50:56 ntpdate[21130]: no server suitable for synchronization
>found
>
>root at xxxxx / # ntpdate -qd 10.251.23.144
>
>14 Jan 08:50:36 ntpdate[21128]: ntpdate 3-5.92d Mon Jul 27 19:20:17 PDT
>1998 (1)
>transmit(10.251.23.144)
>receive(10.251.23.144)
>transmit(10.251.23.144)
>receive(10.251.23.144)
>transmit(10.251.23.144)
>receive(10.251.23.144)
>transmit(10.251.23.144)
>receive(10.251.23.144)
>transmit(10.251.23.144)
>server 10.251.23.144, port 123
>stratum 16, precision -6, leap 11, trust 000<---<<< NOTICE THE STRATUM
>  
>
>refid [0.0.0.0], delay 0.04124, dispersion 0.00125
>transmitted 4, in filter 4
>reference time:    00000000.00000000  Thu, Feb  7 2036  1:28:16.000
><---<<<BOGUS>>>
>originate timestamp: c5924cac.60d03f48  Fri, Jan 14 2005 8:50:36.378
>
>transmit timestamp:  c5924cac.47ae1000  Fri, Jan 14 2005 8:50:36.279
>
>filter delay:  0.04124  0.04124  0.04124  0.04124 0.00000  0.00000
>0.00000  0.00000
>filter offset: 0.088163 0.088163 0.088163 0.098178 0.000000 0.000000
>0.000000 0.000000
>delay 0.04124, dispersion 0.00125
>offset 0.088163
>
>14 Jan 08:50:36 ntpdate[21128]: no server suitable for synchronization
>found
>
>-------------------------------------------------------------------Forced
>my XP laptop to synchronize with the time server and the output
>changes. Notice how the stratum has changed from 16 to 4.
>-------------------------------------------------------------------
>
>root at xxxxx / # ntpdate -q 10.251.23.144
>server 10.251.23.144, stratum 4, offset 0.082606, delay 0.04124
>14 Jan 08:51:48 ntpdate[21134]: adjust time server 10.251.23.144 offset
>0.082606 sec
>
>root at xxxxx / # ntpdate -qd 10.251.23.144
>14 Jan 08:52:01 ntpdate[21136]: ntpdate 3-5.92d Mon Jul 27 19:20:17 PDT
>1998 (1)
>transmit(10.251.23.144)
>receive(10.251.23.144)
>transmit(10.251.23.144)
>receive(10.251.23.144)
>transmit(10.251.23.144)
>receive(10.251.23.144)
>transmit(10.251.23.144)
>receive(10.251.23.144)
>transmit(10.251.23.144)
>server 10.251.23.144, port 123
>stratum 4, precision -6, leap 00, trust 000  <---<<<NOTICE>>>
>refid [10.254.8.30], delay 0.04124, dispersion 0.00063
>transmitted 4, in filter 4
>reference time:    c5924cee.f6c3abbb  Fri, Jan 14 2005  8:51:42.963
><--<<<VALID>>>
>originate timestamp: c5924d01.385d5977  Fri, Jan 14 2005 8:52:01.220
>
>transmit timestamp:  c5924d01.2147b000  Fri, Jan 14 2005 8:52:01.130
>filter delay:  0.04124  0.04124  0.04124 0.05124 0.00000  0.00000
>0.00000  0.00000
>filter offset: 0.090174 0.090174 0.090174 0.085174
>0.000000 0.000000 0.000000 0.000000
>delay 0.04124, dispersion 0.00063 offset 0.090174
>
>
>14 Jan 08:52:01 ntpdate[21136]: adjust time server 10.251.23.144 offset
>0.090174 sec
>
>-------------------------------------------------------------------Ntpdate
>now sees my XP laptop running nothing more than the built in SNTP
>client as a valid stratum 4 time source!
>-------------------------------------------------------------------
>
>I'm not completely clear as to where the reported stratum of my laptop
>is coming from; is nptdate calculating it based on the update time and
>upstream time server stratum or is Windows simply reporting this on
>it's own accord?
>Any thoughts or comments would be greatly appreciated,
>
>Doug
>
>  
>
The Microsoft implementation of SNTP is widely regarded as broken.  One 
of the reasons is that an SNTP client is not supposed to serve time.  
There may be may others!

Q: How many Microsoft programmers does it take to replace a light bulb?
A: None!  Darkness is the new standard. :-)




More information about the questions mailing list