The Secure Time Seeding feature was shipped in the Windows 10 November 2015 (1511) release and is turned on by default. You may have seen the improvements in timekeeping on your Windows tablets and other Windows devices running this version of the OS, but you may have also found issues with broken authentication to SharePoint documents, and devices that go to sleep or start their screensaver well before the time they should have. Interestingly, despite the feature being enabled since November 2015, most sites that are having “weird time issues” have only started since around the Windows 10 Fall Creators Update (1703) and continue even as of the April 2018 Update (1803).
Now, Microsoft did acknowledge that this new service had an issue (KB3160312), however that was listed as being fixed in Windows 10 Anniversary Update (1607)… which clearly isn’t the case for some sites and users. According to the KB article which outlines the “fix”:
This issue occurs because of a problem in the new Secure Time Seeding feature that is part of Windows Time service in Windows 10 Version 1511. This feature uses metadata from outgoing SSL connections from the computer to determine the approximate current time and date values, and it stores this data in the registry. When the computer restarts, the old registry data is not cleared or updated if, for any reason, no outgoing SSL traffic is present since the startup… The system date and time setting on a computer that is running Windows 10 Version 1511 (build 10586.xx) incorrectly reverts to a date and time that is at least one day in the past.
In our environment, this appears to be caused by two things: Web filtering with SSL inspection (Cyberhound), and battery backups in devices such as the Toshiba Portege Z20T. What we identified, is that a device will boot or resume from sleep normally, and would typically be able to log on using cached credentials before the Wi-Fi connection was established and authenticated. After logon, and even for the first short period of time after Wi-Fi has connected, the correct date/time skew is in place so that users can successfully authenticate with domain sites and services. Some time after logon, however, Windows attempts to contact the Secure Time Server and will fail due to SSL-inepection breaking the process, and the system will revert back to the time stored in the registry. Then, at least in our environment, the system would update the time again, to the values stored in the BIOS of the Toshiba devices… and these may now be up to five minutes out of sync with the Domain Controllers, which in turn breaks any secure connections. As described earlier, this resulted in situations where:
- Users were able to successfully open and start working on documents (i.e. Excel spreadsheet) via SharePoint, but a few minutes later, are unable to save any changes.
- Due to the date/time being switched out a couple of times, Windows appears to get confused and triggers various sleep or screensaver settings early, and typically within 2 minutes instead of the 30 minutes defined in Settings.
- A few minutes after logon, if a device is locked, you may not be able to successfully authenticate to resume working on the device, because the time skew is outside that permitted by the Domain configuration.
The fix, is to disable this feature. Here are the instructions as per Microsoft’s article:
I trust my hardware clock and time synchronization mechanisms. I don’t want this!
If you would rather trust your system clock than time data generated from your SSL traffic and want to forgo any benefit this feature gives you, we got your back. Set the following registry value to 0 and reboot your machine and the Secure Time Seeding feature will be disabled. (Standard warning about exercising care while modifying registry applies here).
Registry Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config
Value Name: UtilizeSslTimeData
Value Type: REG_DWORD
Read more about the Secure Time Service here.
Webber Zone 