Why does the Win32 Time service require the date to be correct before it will set the time?
Public Service Announcement: Daylight Saving Time ends in most parts of the United States this weekend. Andy points out that if you attempt to synchronize your clock when the date is set incorrectly, the operation fails with the error message “An error occurred while Windows was synchronizing with time.windows.com. For security reasons, Windows cannot synchronize with the server because your date does not match. Please fix the date and try again.” He wonders what the security risk is. First of all, for people who are trying to solve the problem, the solution is to follow the steps in the error message. Set your date to the correct date, then try again. If that doesn’t help, also set the time to something close to the correct time. Once your time gets close, the time server can nudge it the rest of the way. Back to the original question: What is the security risk being defended against, here? At first glance, you might think that the server is attempting to defend itself against a client whose time is set incorrectly, but actually the potential attack is in reverse: Your computer is protecting itself against a rogue time server. The Kerberos authentication protocol relies heavily on all participants agreeing on what time it is (with some slop tolerance). If somebody manages to fool the client into synchronizing its time against a rogue server (for example, by using a DNS poisoning attack), the attacker can use that invalid date (typically a backdate) as a foothold for the next level of attacks.
The default configuration for the Windows Time service is to reject attempts to change the clock on domain-joined machines by more than 15 hours. You can change the configuration settings by following the instructions in this KB article (which happens also to have been the source material for most of this article).
Light
Dark
0 comments