[ntp:questions] Windows Time with NTPv4
David L. Mills
mills at udel.edu
Fri Mar 14 00:00:06 UTC 2008
Remember, enable/disable auth has nothing to do with authentication
itself, just whether new associations can be mobilized if no
authentication is used. In your case a symmetric passive association was
apparently mobilized and began sending mode-2 packets just as if a
legitimate peer was involved.
Windows was apparently happy with the reply, even if it was up to 64
seconds delayed, and apparently successfully ignored subsequent mode-2
packets sent from the association until it timed out.
These are probably unintended consequences, so disable auth is probably
not an optimum workaround. Better to use the Windows workaround. I have
included a link to the Microsoft KB in the latest documentation and will
provide some way to selectively activate the workaround mentioned
Evandro Menezes wrote:
> On Mar 13, 3:56 am, Martin Burnicki <martin.burni... at meinberg.de>
>>Do the Windows system run ntpd or w32time? If they run ntpd then
>>authentication could be configured correctly. I don't know how any version
>>of w32time could be configured to support NTP's symmetric keys or even
> They run w32time.
>>This seems to indicate that ntpd is running on the XP machines and has been
>>configured correctly with authentication.
> Actually not. I had this in ntp.conf:
> restrict default kod limited nopeer
> tos orphan 4
> enable bclient
> disable auth
> Then, the w32time systems appeared as servers in the output of "ntpq -
> p" and "ntpdc -c listpeers" confirmed their status as peers.
> When I removed the last line above, as w32time doesn't support
> authentication keys, the w32time systems stopped showing up as
> servers, even though their association mode remained 1. So w32time
> was happy, believing it was a peer (if it indeed behaves as a peer is
> left to be demonstrated), and NTP kept on working without the
> interference of w32time in its choice of servers.
>>Of course the admin of a NTP server does not want his NTP server's time be
>>changed just because some dumb client sends some packet asking to do so.
> But I think that with the proper restrictions NTP will do the right
>>This is what happens with w32time which under certain conditions sends
>>"peer" requests instead of "client" requests. Since those w32time clients
>>have neither been configured nor authenticated as peers, the question is
>>how they should be handled by ntpd.
> I think that they're being handled just fine by NTP. NTP does what
> ntp.conf tells it to do and it can handle w32time stupidity just fine
> as in my case above.
More information about the questions