6

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.

kernelpanic
  • 1,246
  • 1
  • 10
  • 30
Ryan Ries
  • 55,011
  • 9
  • 138
  • 197
  • 1
    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: http://support.microsoft.com/kb/956627 – Shane Madden Oct 20 '12 at 19:19
  • 1
    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
  • 1
    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 09:00
  • This is a really cool topic, but in retrospect, I think I might vote to close my own question on the grounds that it's not really question, but rather a good discussion. The only answer I can think of is "some apps break, some apps don't. Depends on how well they stick to RFC 4430." – Ryan Ries Feb 28 '13 at 00:32

0 Answers0