Update 4/30/2025:
Official recommendation to disable Secure Time Seeding on DCs can be found here:
Secure Time Seeding Recommendations for Windows Server - Windows Server | Microsoft Learn
Hello all, Chris from Directory Services here again. Lately, we’ve seen an increase in cases where DCs (Domain Controllers) suffer issues with time jumps, many times into the future. As everyone here knows, time synchronization is critical for Active Directory and other applications. As time has passed (hyuk hyuk), we’ve seen some interesting scenarios from simple misconfigurations to the Great Rollback. Regardless of the cause, these issues were capable of causing huge outages for customers, so in Server 2008, we released a new default value for w32Time’s protection configuration.
MaxPosPhaseCorrection and MaxNegPhaseCorrection defaults were changed from “take literally anything” to 48 hours. We’ve also released various guidance on configuring Domain Controllers for NTP:
So what brings us here?
Well, with Server 2016, came Secure Time Seeding (STS). Further commentary addressed this release as a more of a client solution and not as an accurate enough solution for Active Directory. However, Secure Time Seeding is enabled by default on all currently supported Windows Server OSes. Furthermore, it does not honor MaxPosPhaseCorrection or MaxNegPhaseCorrection. CSS has seen high production impact at customer sites due to STS setting an incorrect time when TLS connections are made to woefully misconfigured devices.
Wait, what?
You can probably see where this is going. We urge all Active Directory administrators out there to take this information and consider whether this is something you want or not. From the w32time blog post above:
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
To compound the issue even further, there is no logging that will point to STS as having set the time. The only way to know that it made the change is to already have w32tm debug logging enabled before it happens where you would see something like this:
152929 22:35:45.3014352s - ClockDispln Discipline: *SET*SECURE*TIME*
Running w32tm debug logging 24/7 is not going to be something we would ever recommend unless we absolutely had to, similar to most other debug logging.
So, where do I stand?
Here’s a command that will allow you to see the value on all your DCs:
For /f %i IN ('dsquery server -o rdn') do REG QUERY \\%i\HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Config /v UtilizeSslTimeData /t REG_DWORD
In conclusion, while Secure Time Seeding offers potential benefits, it is possible for issues to arise with Active Directory. Administrators must weigh these considerations carefully when deciding whether to disable this feature. Additionally, consider that this can impact non-DC servers in productions as well. The decision should be based on the specific needs and configurations of their environment.
Chris “All this Time” Cartwright
References:
https://techcommunity.microsoft.com/t5/ask-the-directory-services-team/bg-p/AskDS/label-name/Time
https://techcommunity.microsoft.com/t5/ask-the-directory-services-team/bg-p/AskDS/label-name/w32time
Microsoft
