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).

Comments (43)
  1. Matt Fisher says:

    Is it possible for a rogue server to ease the time backwards by 15 hours per shot?

  2. Joshua Ganes says:

    I have seen this error once and was slightly puzzled by it. I followed the suggested steps in the error message, and the problem was solved. Given the approach suggested in Matt Fisher's comment above, I would say that the 15 hour safety net makes life more difficult for an attacker, but is hardly a strong source of security. I found it much more irritating as a user that a service intended to set the correct time complained that I didn't have the correct time to start with.

  3. Wladimir Palant says:

    @Matt Fisher, Joshua Ganes:

    Time synchronization only runs once a week. Even assuming that a rogue server is operating continuously and undetected, it will only be able to skew the computer clock by 15 hours per week. Setting the clock to a date a few years back (most likely the point of this attack) will still be impossible.

  4. zeno490 says:

    Yes I've been bitten by this several time as I am in possession of a rare item: a time traveling laptop. My motherboard is fuubar and sometimes, the clock will travel backwards, sometimes several days/weeks/years…

  5. Alex Grigoriev says:

    Do systems in a domain synchronize their time to an external server or to the domain controller?

  6. ErikF says:

    ntpd does something similar: the 4.1.0 documentation (doc.ntp.org/…/ntpd.htm) says that it the daemon quits if the local clock is more than 1000s away from the reference clock.  I found this out the hard way when I was setting up an old laptop with a malfunctioning CMOS battery!  Yes, this behaviour can be overridden by specifying "-g", but at first it seemed non-intuitive to me.

  7. Alex Grigoriev says:

    OK, I'm lazy. "All the client desktop computers nominate the authenticating domain controller as their authoritative time source."

  8. nathan_works says:

    I've had similar issues with doing SSL connections on .net/IIS web services.. SSL, DST, and clocks out of sync makes for difficult-to-track problems.. (I can't recall if ssldiag helped or not .. )

  9. Jaanus says:

    Raymond, do you think that what you describe is good systems design? How common are rogue time servers vs people's clocks being wildly off? To me, it sounds like an instance of designing for a rare corner case while making the common case's life more miserable.

    [Bad guys love rare corner cases. -Raymond]
  10. Oliver Taylor says:


    In many cases security exploits will make a customer's life more miserable than having to change the date.

    Of course it is swings and roundabouts, but I suspect that those who suffer from malware or viruses would prefer that those on the development teams that deal with windows make design decisions that reduce the chances of their system being compromised.

  11. Peter Ibbotson says:

    When I was trying to get our domain correctly setup (we always used to see w32time errors in the event log) I found a control panel applet from greyware called Windows time agent (it's freeware) absolutely brilliant in helping me figure where machines thought they were getting time from.

    In the end the problem was being caused by VMs and their host servers having different ideas as to what the time was.

  12. Leo Davidson says:

    @Wladimir Palant: "Time synchronization only runs once a week."

    By default, but not always.

    The motherboard clocks on both my computers are so unreliable that I had to make them sync once a day to avoid accumulating ridiculous clock drifts (5 min or more over just a few days!) which messed up TV recordings etc.

    Getting the Windows 7 time service to sync more than once a week turned out to be fairly complex, too, and the solutions I found on the web didn't actually work. (I think it's due to there being two schedules to worry about: one for when the service runs and one for what the service does when it runs. Perhaps it's a side effect of the (good) work done in Win7 to prevent services running when they don't need to.) I put my findings here in case they're of use to others:


  13. Gabest says:

    I always wondered if a time service could exists like p2p file sharing. No one would know for sure if he has the correct time, instead they asked their connected neighbours and took the average, ignoring the values that deviate too much of course. After a certain number of clients the time set in this network would be automatically precise forever.

    [That would eliminate random drift, but it would be susceptible to systematic drift. (For example, due to rounding, the PC clock runs 0.00015% fast. If more than 50% of the machine in the neighborhood are PCs, then the collective clock will run fast.) -Raymond]
  14. Marquess says:

    In other news, Europe (or at least the Central European Time zone) already fell back last weekend.

    [Not sure what your point is. Should I announce every time zone change worldwide? -Raymond]
  15. Marquess says:

    Only trying to be informative.

    Also we're ahead of ya.

  16. NT says:

    Raymond, please ban comments from people who live in the future.  They could cause a tear in the space-time continuum if they reveal any substantive information to us.

  17. Joshua says:

    So *that's* why we can't override the local time server settings even when the domain controller's time is fubar'd.

  18. Erzengel says:

    I have to agree with Ian Boyd.

    Since I don't have time to try and parse the source article, I'll just ask: Is there any way to tell it "I, the administrator, accept the risk of a rogue time server. Since I am manually saying 'update time', just do what I told you to do and update the time."

    [Yes. See the source article for details. -Raymond]
  19. Ian Boyd says:

    Can i just say that if the source article were written this clearly i would have easily understood it. You have a way to taking some hard to follow documentation and clearing it up. And like Don Box's book: by explaining the *why* you make the *what* easy, and essentially obvious. That's why i bought the book.

  20. even when the domain controller's time is fubar'd

    The primary domain controller should have its time server set to an authoritative off-domain NTP server.  Otherwise the entire domain will drift out of sync with the rest of the world.

    I'm not sure what to do for backup domain controllers.  I would say configure them to use authoritative off-domain NTP servers too.  I would guess that while they are BDCs they slave to the PDC, and if they get promoted to PDC they revert to their NTP server setting.

  21. Martin says:

    @Gabest If you are using NTP to synchronize your time, ntpd supports a so-called "orphan" mode which must be explicitly configured, in case it is important to you that the (local) network stays in sync with each other but not with the "real time", in case connection to external time sources is lost.

    Have been using this very successfully in some scenarios, where synced time between participants in the system was important, but the internet connection was rather unreliable.

  22. Z says:

    this seems like a workaround designed to avoid handling the actual issue: proper validation / trust of the time server.

    i don't know the ins and outs of the time protocol used here, but couldn't this have been solved by using secure connections (TLS) and validating the server certificate? perhaps only allow certs signed by a certificate authority owned by Microsoft. this way, Microsoft would get to control whether a time server is valid enough to be accepted by Windows clients or not.

    [You must not get out much. If Microsoft did that there would be a riot. "You're telling me that if I set up a domain in my organization, I need to get Microsoft to issue a certificate to each of my my domain controllers so my clients can use it as a time server?" -Raymond]
  23. Actually Z has a point.  In the domain scenario there's already a trust relationship between the NTP client and the NTP server.  It should be possible to use a secure version of NTP that builds on top of that trust relationship… that would fix the "rogue server" issue in that specific scenario.

    In principle it would also work for non-domain scenarios if internet "secure NTP" servers published public keys, which the client could indicate trust in at the time they decided which NTP server to use.  These could be self-signed.  That would vastly limit the attack window.

  24. grumpy says:

    @Z, @Mauritz, you're just missing one fairly obvious point here:

    how do you define a trustworthy time server?

    I can see one, and only one, sane definition: A trustworthy time server is one that reports the correct time.

    I don't care how many certificates it has, if it tells me the wrong time. And vice versa, as long as it tells me the correct time, I couldn't care less who has, or has not, signed its certificates.

    So it makes good sense that in order for me to trust a time server, it has to report a time that is close to what I happen to know the time is. This is pretty sensible behavior, and I'd hate to have to rely on arbitrary certificates that don't tell me what I need to know (that the server reports the correct time), but only that Microsoft trusts the server (that's nice too, but it's not as important as whether it reports the correct time).

    @Jaanus: no, I'd say it's the other way around. A user's clock suddenly diverging dramatically (by default, more than 15 hours per week) sounds like a rare corner case (and it's usually a symptom of a hardware malfunction, and then it doesn't really matter what the time server does. Your clock will drift off again almost immediately after synchronizing). But a potential security vulnerability is pretty much by definition never a corner case. If it can be exploited, it will be exploited. And then it's no longer a corner case.

  25. osexpert says:

    I don't get it. Wiki says "Kerberos has strict time requirements, which means the clocks of the involved hosts must be be synchronized within configured limits." So what if some bad time server give me the wrong time, it would "only" mean that Kerberos would not work: "Sorry, your time deviate more than 5 minutes". In case, it sounds like DOS problem, not a security problem. Also, if Kerberos require max 5 minute deviation, why the heck is not time synchronization built into Kerberos? Sounds like a badly designed POS.

  26. how do you define a trustworthy time server

    One that I have made a conscious decision to trust.  Part of this is being able to reliably identify the time server a given NTP packet actually comes from, perhaps via an extension to NTP (S-NTP, we could call it) where packets include something that could only be generated by the holder of the private key that corresponds to the public key I pointed to when I set up time synchronization.

  27. Erzengel says:

    [Yes. See the source article for details. -Raymond]

    Excellent, when I have the time I'll go take a look for the next time I have a motherboard that's reset its time.

  28. Paul says:

    @osexpert: If there is already a well adopted and understood protocol for synchronising time why reinvent the wheel and duplicate this effort as part of the kerberos protocol? What would happen if a pc was set to sync via ntp and also was part of a domain – it now has two time sources. Do we ignore the ntp source as long as a kerberos server is available but fall back if one isn't – that could result in temporary network outages causing clocks to be more out of sync than if we did nothing at all. If we ignore the ntp setting completely then that is just going to cause confusion.

    Although the article was referring to kerberos there could be other authentication mechanisms in use that do not enforce a requirement on time anyway.

  29. Semi Essessi says:

    Why have the limit at all? If you make it public then I would expect that attackers would modify their attacks accordingly (they can Google it when their first attack fails) – its only marginally more secure than having no limit at all. Unfortunately having the limit inconveniences users and, from the naive perspective, makes it look like Microsoft failed to solve a trivial problem properly.

    I'd expect having the limit is only going to protect against the most useless and undetermined of attackers – who are the least threat anyway.

    Still… interesting to know about. :)

  30. Cheong says:

    How about that, by default the domain should generate a certificle for NTP source authentication purpose only that all computers joining domain be trusted. This certificate will be updated as other domain-wide certificate deployment.

    Time service will update only with those NTP which have Microsoft or domain generated certificate, when required to ignore the 15 hour limit.

    [Suppose Microsoft did that. You made it impossible for people to switch to ntp.org as their time server. Who's the evil one now? -Raymond]
  31. Gabe says:

    I think that Cheong was trying to imply that a domain-generated or Microsoft-generated certificate would automatically allow the time service to ignore the 15-hour limit. It would only be with untrusted NTP servers that the HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesW32TimeConfig limits would need to be enforced.

    Given that there probably close to a billion computers that sync to time.windows.com once a week by default, that equates to over 1,000 requests per second against MS time servers. I'd guess that MS would probably skip the signing and just leave it up to the domain-connected systems where time sync really matters to do the secure NTP.

    [I guess that could work, but it would also increase the load on the time servers (having to digitally sign every response) to cover a corner case that can be fixed by the end user by simply following the instructions. Good luck justifying that infrastructure budget. -Raymond]
  32. Jon says:

    Raymond, it's pretty hard to get an "end user to follow the instructions" when you want to automate the solution. Signing could be done only as a second phase, when the initial request fails due to incorrect date. I wonder how much the load would be affected then.

    [My reading of NTP is that there is no way for the client to indicate whether it wants the response signed or not. The server, if it supports signing, must sign everything. But I didn't spend a lot of time researching NTP. (In that respect, I'm following the lead of most commenters.) -Raymond]
  33. NTP doesn't support a concept of signing at all.  There would need to be an extension to NTP to allow the client to verify the identity of a server.

    I don't see that the load is significant.  NTP packets are just calculated every so often.

    A more serious design concern is that the rogue time server could just replay old packets from the real time server.

  34. time2time says:

    Why the arbitrary 15 hours default limit? Why not 14 or 16? What makes 15 better than everything else?

    [Why the arbitrary 14 hour limit? Why not 13 or 15? -Raymond]
  35. Goldilocks says:

    Because 14 is too little and 16 is too much.  15 is just right.

  36. Cheong says:

    @time2time: My guess would be GMT +/- 12 hours difference in timezone + 1 hour possible daylight saving adjustment in U.S. + 1 hour possible daylight adjustment in other countries + allowance for 00-59 minutes deviation in time.

  37. Cheong says:

    [My reading of NTP is that there is no way for the client to indicate whether it wants the response signed or not. The server, if it supports signing, must sign everything. But I didn't spend a lot of time researching NTP. (In that respect, I'm following the lead of most commenters.) -Raymond]

    Currently NTP works on UDP, how about adding TCP 123 for SSL enabled NTP, and make RFC require NTP clients connect with NTP first, and then connect TCP if connection through UDP fails or time skews more than 15 hours, and always assume TCP NTP connection will always be SSL enabled?

    In this way the old clients would just work, and the infrasturcture investment shouldn't be huge, as people only need TCP one on "corner case".

    That said, even if not implemented this way, I think the loading for intradomain NTP request should be quite acceptable for most companies.

  38. Cheong says:

    /adjustment in U.S./adjustment in NTP server time/ for reply to time2time

  39. nobugz says:

    @Cheong – I like the thinking but it does ignore somebody hopping back and forth across the International Date Line.  25 hours to make that hop sufficiently impractical.  Ignoring UTC+14, Kiribati is on my bucket list.

  40. Random832 says:

    Raymond, the obvious answer is to connect to a different IP and/or port. However…

    Everyone who's suggesting some sort of digital signing idea – what happens when the client machine thinks the certificate has expired?

    Everyone who thinks it has to do with moving between timezones – the windows system time and NTP are maintained in UTC.

    Maurits – see rfc 5906 – the load for a pki-based system is significant, thought has been put into replay attacks, but there doesn't appear to be a solution requiring no configuration on a client whose time may be off by an arbitrary amount in either direction.

    It seems like the attacks involving a rogue NTP setting the date to some point in the future are much less clear than those involving setting it to the past, and the [wrong] client clock being set in the past [and being moved forward a large amount by a correct NTP server] seems like a more likely scenario than being set in the future – so a plausible solution might be to only apply the limit for setting it backwards.

  41. Mark Wooding says:

    @cheong: Running NTP over TCP is crazy.  In particular, the server's reply packet is meant to contain a timestamp for when the packet was transmitted.  TCP retransmission and congestion control delays would completely destroy the server's ability to predict when the packet is actually sent.  Currently, properly configured NTP (with a number of reasonbly low-stratum servers) can keep a client's clock within a hundredth of a second of true; there's no way that could happen over TCP.

    Note also that introducing nontrivial cryptography makes this sort of thing way more complicated.  I suspect that a server would have to predict an upper bound for when (say) it will have finished signing a packet, put that time, and the time when the client's request was received, in the message to be signed, send it off to the crypto engine — which may be a hardware security module, communications with which will introduce unpredictable latency (it might be network attached, for example) — and then /delay/ transmission of the finished signed response until the predicted time.  (You could just try to include the crypto as network latency overhead, but it's a strongly asymmetric overhead so I think that'll cause clients to lock onto the wrong time.)

    Alternatively, you could set up a persistent association with symmetric session keys between the server and each client — but then the introduction of per-client state will severely limit the number of clients that the server can deal with simultaneously.  You could mitigate that by deepening the forest of servers, but then leaves will be further adrift of true time.

  42. Cheong says:

    @Mark Wooding: I see. In that case, how about introducing SSL for just authentication purpose?

    A machine connects to NTP server, seeing clock skew by 15+ hours, then connect to TCP port to check the e-cert. After confirmed server identity, resume normal time-sync process with UDP. The authentication will be valid for a specified amount of time (sort of TTL in DNS servers) and NTP clients need not connect TCP port if the authentication status is still valid.

    I guess the addition loading it'll receive will be no more than average popular webmails. (Afterall, after the certificate is checked, it can be returned and no other content is needed)

    For authentication purpse, I guess kerbose or others could do too. Just that for e-certificate you can limit the purpose of what the certificate can do, hence reducing chance of possible unwanted side effect in introduced.

  43. Drak says:

    Maybe allow 3 different time sources? Then if 2 agree, and one is way off, use those 2. If they all disagree (within limits), you'd still be screwed but at least Windows would know something's up.

Comments are closed.

Skip to main content