Time Sync on Windows Domains

Time synchronization is vital for active directory domain-connected PCs because the Kerberos ticket protocol required to log into the domain, will not work if the two clocks are more than "five or so" minutes apart (the exact value being a GPO configurable option)

Most of the machines on my network connected to the domain run Linux, and the three domain controllers also run Linux, so the handful of Windows devices and VMs are the odd ones out, unusually enough.  Most Windows domain networks are mostly or even exclusively full of Windows servers and desktops.

Between Linux servers, time sync is unimaginably simple.  Add a "server" line or two to the /etc/ntp.conf file, and run some diagnostic commands to verify, if necessary the text based log files in /var/log/ntp are self-explanatory.  SystemD makes things much more difficult and complicated, but its still relatively easy to get times synced between Linux machines.

Windows... is a little more elaborate, a little less documented, and the CLI is much harder to use.  I had to assemble perhaps 20 to 30 web page query results to generate this little "cheat sheet" for your reading entertainment.

Autoconfigure Windows time service from the AD Domain

On Unix if you want NTP protocol, you install NTP, or if you want some other protocol you install some other suite.  On Windows, there is a single multi-protocol subsystem.  Possibly you could install some 3rd party software to implement alternative time sync protocols.  So regardless of selected protocol, everything in the w32time subsystem is controlled via the w32tm command (not a typo, and yes it's aggravating)

Who knows what happened in the past, Windows is somewhat nondeterministic, so a reasonable first step is to implement a solid base configuration over whatever may be left behind from the past; there may be legacy config data stuck in the system.  Let's point the Windows desktop to autoconfigure its time sync from the domain.

Run CMD.EXE as administrator, and take a look at the output of

• w32tm /query /configuration

To update the config you probably need to run something like:

• w32tm /config /syncfromflags:domhier /update
• net stop w32time
• net start w32time
• w32tm /resync /rediscover /force

You will find many claims online that this will work, and the old fashioned "net time /set /y" is obsolete and unneeded, unsurprisingly, that internet karma farming advice is wrong and I needed to use the old "net time" commands initially.  NTP will phase itself into synchronization if the times are too far apart. However, it takes forever and seemingly does not work sometimes.  It's easier to reset the clock to a known accurate time using the "net time" process above, at least to start.

(insert ominous foreshadowing music here) The default time sync protocol for a domain-connected PC is NT5DS protocol, not NTP, and it will point to a single domain controller for time sync, not all three DCs in my DC cluster.  In the long run I did not want either of those configuration options, LOL.

Verify Windows time sync subsystem operation

This is enormously more complicated than running "ntp" on linux and typing "help" a couple of times.  Sorry.

Run CMD.EXE as administrator, then:

• w32tm /monitor

Outputs a report of the DCs ntp status, very cool, "walks up the tree" reporting the upstream server's information.

• w32tm /stripchart /computer:dc03.cedar.mulhollon.com

Reports a live continuous stream of NTP polls against an individual computer, in this example, my third DC in the DC cluster.

• w32tm /monitor /computers:10.10.8.221

Reports data on one computer (offset, refid, etc) in this case DC01 aka 10.10.8.221

• w32tm /query /source

Lists where the clock is currently synced. Probably should NOT be "Local CMOS Clock"

• w32tm /query /status /verbose

Lists timers and recent errors/results.  State machine should be 2 (Sync) not 0 (Unset)

• w32tm /query /peers /verbose

Lists individual peer data, including reachability counters and state

• w32tm /query /configuration

Dumps the current time sync subsystem config. Note the line describing "type" NT5DS (Local) instead of using the NTP protocol.  Note this is not like a modern Unix config yaml file where you can edit it and feed it back to the config, you will have a hilarious fun time trying to figure out how to change the NtpServer line or the MinPollInterval line, and good luck figuring out what "CompatibilityFlags: 2147483648 (Local)" means.  Windows is not exactly user-friendly, LOL, but it can be badgered into working eventually.

Configure NTP on a UNIX machine to supply NT5DS time sync

You need to follow the instructions on the samba wiki page, but take them with a grain of salt in 2024.

ntpsigndsocket needs to be /var/lib/samba/ntp_signd/ on a 'modern' Ubuntu server, not the  /usr/local/samba/var/lib/ntp_signd/ suggested by the Samba wiki.

In the "restrict" lines, you need to add mssntp to enable the NT5DS protocol

Note that despite my optimistic instructions above, I can't get NT5DS to work at this time; just get a meaningless error message and the logs look "OK" on the DCs and nothing ever syncs up, so it's unclear exactly what is broken.

Give up and configure the Windows machines to use world standard NTP protocol instead of NT5DS protocol

I only have three machines running Windows on the domain, so there are diminishing returns to continuing to burn hours troubleshooting the NT5DS time protocol.  Windows machines can be configured to use the NTP protocol via the following process:

Run CMD.EXE as administrator, then:

• w32tm /config /manualpeerlist:"10.10.8.221,0x8 10.10.8.222,0x8 10.10.8.223,0x8" /syncfromflags:MANUAL
• net stop w32time
• net start w32time
• w32tm /resync

The ',0x8' stuff in the config above is to force a client-type NTP connection and not make a bidirectional peer-to-peer NTP connection.  There's a MS knowledge base article about the MS side crashing if the NTP side fails to cooperate, if it doesn't allow p2p time sync connections.  I trust my server clocks more than I trust my end-user desktop clocks anyway, LOL.  IP addresses .221 .222 and .223 are my three DC cluster machines in the example above.  Yes, multiple NTP servers separated by spaces and that's why the option has to be wrapped in quotes, don't need quotes if you only have one NTP server...  Yes in theory you will be told you don't need to "net stop" "net start" but in practice I found I had to, to "kick" the subsystem into properly reacting to the new config.

Summary and the Future

Now, things "just work" for the three or so Windows machines on my network using NTP protocol for time sync.  It would be interesting to fix NT5DS time sync protocol someday, but I'll use the more standard NTP protocol for now.

I think my NTP servers are OK, and it's probably a Windows thing, probably something weird about the crypto security keys, or maybe Samba is not talking to NTP in some way.

In the long run, this should all be a centrally configured GPO but I only have three machines to hand configure, so it seems OK... for now.