Local and Domain NTP Overridden by Secure Time Service

Posted on by

Starting with Windows 10 1511, Microsoft introduced a new feature called Secure Time Seeding, part of the Secure Time Service (STS), as an upgrade to the W32TIME service. The STS uses information from SSL connections to validate NTP data. Information from this feature supersedes all other time sources, including locally configured NTP, domain controllers, and Hyper-V time synchronization.

I first noticed the feature when several of my Hyper-V virtual machines began shifting their system clocks backwards and forwards several times a minute. At first the time changes spanned a few hours, but as the machine uptime climbed, so did the time jumps. Eventually, the time was bouncing backwards and forwards by weeks, several times a minute. The Hyper-V time synchronization service was fighting with the new Secure Time Service and this wrecked havoc on authentication and any other services running on the systems.

The issue appeared limited to machines with proxied or restricted internet connectivity. These were also machines that didn’t run 24/7 and were suspended in Hyper-V when the lab environment was not running. This combination seemed to cause the Secure Time Service to reject the domain NTP data, starting a few days after each reboot.

Enabling the debug logging on the W32TIME service had the following relevant entries. As we can see from the log, in this instance STS was reverting the system clock backwards six days.

152835 16:50:16.7845522s - Setting the system time because it is outside the secure time limits.
152835 16:50:16.7845801s - Current system time: 16:50:16.784 6/14/2019
152835 16:50:16.7845937s - Target system time: 13:5:38.828 6/8/2019
152829 13:05:38.8297685s - ClockDispln Discipline: *SET*SECURE*TIME*
152829 13:05:38.8300909s - W32TmServiceMain: ********** Time Slip Notification **********

After STS would revert the clock, w32tm /query /status would report that the time source was “Free running system clock,” and would remain there until Hyper-v intervened a few seconds later. Rinse, repeat.

The feature can be disabled through a registry key.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config
DWORD: UtilizeSslTimeData = 0