What breaks in a Windows domain if a member has a high time skew?
- by Ryan Ries
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.
