Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

It's taken for granted by most IT people that in a Windows domain, if a member server's clock is off by more than 5 minutes (or however many minutes you've configured it for) from that of its domain controller - logons and authentications will fail.

But that is not necessarily true. At least not for all authentication processes on all versions of Windows. For instance, I can set my time on my Windows 7 client to be skewed all to heck - logoff/logon still works fine. What happens is that my client sends an AS_REQ (with his time stamp) to the domain controller, and the DC responds with KRB_AP_ERR_SKEW. But the magic is that when the DC responds with the aforementioned Kerberos error, the DC also includes his time stamp, which the client in turn uses to adjust his own time and resubmits the AS_REQ, which is then approved.

This behavior is not considered a security threat because encryption and secrets are still being used in the communication.

This is also not just a Microsoft thing. RFC 4430 describes this behavior.

So my question is does anyone know when this changed? And why is it that other things fail? For instance, Office Communicator kicks me off if my clock starts drifting too far out. I really wish to have more detail on this.

edit: Here's the bit from RFC 4430 that I'm talking about:

If the server clock and the client clock are off by more than the
policy-determined clock skew limit (usually 5 minutes), the server
MUST return a KRB_AP_ERR_SKEW. The optional client's time in the
KRB-ERROR SHOULD be filled out. If the server protects the error by
adding the Cksum field and returning the correct client's time, the

client SHOULD compute the difference (in seconds) between the two
clocks based upon the client and server time contained in the
KRB-ERROR message. The client SHOULD store this clock difference and use it to adjust its clock in subsequent messages. If the error is
not protected, the client MUST NOT use the difference to adjust
subsequent messages, because doing so would allow an attacker to
construct authenticators that can be used to mount replay attacks.

share|improve this question

closed as not a real question by Ryan Ries, mgorven, Sven, mdpc, Khaled Feb 28 '13 at 8:04

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.If this question can be reworded to fit the rules in the help center, please edit the question.

I'd think some non windows based AD clients might not accept the time change. so in other words they are not RFC 4430 compliant – tony roth Oct 19 '12 at 16:20
See also: – Shane Madden Oct 20 '12 at 19:19
What type of time source are your clients configured to use? NTP or NT5DS? – Mathias R. Jessen Dec 16 '12 at 23:00
To answer your question I'm just using the default NT5DS domain hierarchy, with the PDCe syncing from an Internet time source... – Ryan Ries Dec 17 '12 at 18:59
FYI, it is not considered a security issue to cope with differing clocks in this way because the function of the timestamp is to prevent replays, which this approach also serves to do. Encryption and secrets do not protect against replays. – Slartibartfast Feb 21 '13 at 9:00