Holy cow, I wrote a book!
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."
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
You can change the configuration settings by following the
this KB article
(which happens also to have been the source material
for most of this article).