Score:1

Windows time service sync to external ntp servers only if they coincide

cn flag

I recently had a problem which I've never seen occur before. One evening around 2030 one of the DC's changed its clock back an hour. This server syncs to two addresses in pool.ntp.org. Nobody was present when this occured and the event logs clearly show time-service syncing against a public ip.

I can only assume that we hit a server which was incorrecly configured because, after the chaos the following morning caused by the building management systems having the wrong time, I simply resynced the ntp server and it immediately corrected its clock.

I normally have ntp configured to use two different ntp servers so I assume that the client only connects to the first one which responds and just assumes that it will supply the correct time.

so, my question:

Is there any way to configure the windows time service so that it will only correct its clock after consulting two different ntp servers and they both coincide as to the correct time? I'm running Win2019

Edit: I hadn't known it was possible to do historical querying on ntp results(thanks Paul Gear). Querying for the two IP's I had configured s shows the cause of my problem:

1623189765,"2021-06-08 22:02:45",-0.003809235,1,13.2,,,0,
1623188607,"2021-06-08 21:43:27",6.1543e-05,1,12.8,6,"Newark, NJ, US",0,
1623188607,"2021-06-08 21:43:27",6.1543e-05,1,12.8,,,0,
1623187438,"2021-06-08 21:23:58",0.011513196,1,12.4,6,"Newark, NJ, US",0,

The middle line there indicates a huge variation from the server I was using.

Score:1
cn flag

Not to disagree too much with John Mahowald, but snce Windows 2016 at least, Windows Time Service has been much improved, including a full NTP service. They also have a document explaining how to configure Windows for high accuracy. I don't think there's any need to run a separate non-Windows NTP server unless you have extremely high precision requirements (in which case, you'd probably use PTP instead - there's even support for that in Windows 2019).

So most likely, you have just run up against an inaccurate pool server. This happens from time to time, and the pool is very good at removing these servers quickly. If you have a record of the IP address of the server it was syncing to, you can look up its history at https://www.ntppool.org/scores/<IP_ADDRESS>.

I think it's probable that because the system in question was still responding, it was selected because you have too few peers configured (see also the following section in RFC8633 about having a diversity of reference clocks), and Windows Time Service didn't need to re-query the pool for a new IP because the original server was still responding.

So the most important thing you can do to prevent this from reoccurring is, as John said, add more time sources. More sources from the pool is fine, and if you want something outside the pool which has pretty stable IPs and offers a reasonably accurate service, try time.apple.com, which appears to be a Geo-DNS pool of globally-distributed stratum 1 servers.

cn flag
I configure all DCs via scripts so that they have two alternate ntp sources. This server had two sources and some 15 hours earlier it had been rebooted and eventlog shows that its servers were 5.148.175.134 and 90.165.120.190, so it did have two which it got from ntp.org, but the clock was adjusted based on just one of those IPs responding with an incorrect clock. I'm trying to work out if I can set them all up with 3 clocks and only have windows update the time if two ntp servers match times, ignoring an ntp server returning a wildly incorrect time.
cn flag
I should add that the wording in the documentation talks about the service comparing multiple sources to select the most accurate source. What it doesn't indicate is if this is a one off when the service loads or reconfigures or if this occurs whenever it periodically checks the local clock. I suspect it only occurs once, which isn't going to avoid the problem of an ntp source, which is normally ok, suddenly returning an incorrect time.
John Mahowald avatar
cn flag
If w32time has 3+ sources configured, and one of them jumps by an hour, will it detect a false ticker and not step? I have not found documentation on this behavior.
cn flag
I didn't think it would do this, but I always have two sources configured and the event logs don't lie. I have a single entry from time-service saying it was changing its time and it switched back exactly one hour. Earlier eventlog entries indicate the ip's of the two sources it was using and the ntppool.org/sources page indicates that just one of those two had a time issue... my bad luck was that the server was seemingly using that as its primary and didn't check against the second.
Paul Gear avatar
cn flag
TL;DR: two sources is not enough. Don't think about 2 vs. 3. Think about 2 vs. 10. (The NTP BCP RFC linked in my answer recommends a *minimum* of 4.) I don't have a Windows server to test on, but if I read the documentation correctly, it is now a full NTP implementation and it should be *constantly* comparing its upstream sources via the intersection algorithm (see the diagrams I collected at https://is.gd/xW2qbb), meaning that if you have a suitable number of peers you should never get into the situation you experienced.
cn flag
@paulgear excellent posting on your blog. Theres a lot to digest but I think it answers my question.
Score:0
cn flag

w32time is only a SNTP client, far as I can tell, so if the packet has a big jump the time will be stepped. Group policy can be configured to have additional NTP servers, but these are for fallback on failure, not multiple associations at once with error checking like ntpd.

Consider running your own not-w32time service in front of AD DS, a full NTP implementation with multiple sources. Take your pick, physical appliance with GNSS antenna, ntpd or chrony install.

Four sources, from the NTP pool perhaps if internet is available, is better than two. Easy with ntpd or chrony.

pool 2.pool.ntp.org
cn flag
Adding another layer in the middle isn't going to solve anything unless the ntp server in the middle only changed its clock in response to multiple identical responses from public ntp servers and not just a single one. I haven't investigated yet if using a linux based ntp server would allow this.
vidarlo avatar
ar flag
@IanMurphy NTPd configured with 3-4 clocks will ***not*** change it's time based on one outlier. It will select a trusted reference based on the sum of all available information.
cn flag
That would be a solution if ntpd works that way. Now I have to try it out and see if I can break it. Thanks
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.