Danny Mayer wrote: > Jeffrey Altman wrote: > > That is a risky strategy and I wouldn't recommend this to anyone though > I understand the realities of this having been bombarded with questions > about time zones back in March and April. There are ways of updating the > zone tables even for Windows 2000 and NT 4.0 even without Microsoft's > support. You are assuming that you control the client machines. Most home users simply do not know that they even need to perform the updates or how to perform them. If they are using Win9x still (and trust me there are plenty of them), then there aren't even updates available from Microsoft. > >> It is crucial is that the KDC and Kerberized services have their clock >> synchronized. However, >> it is possible for clients to have their clocks off by a period greater >> than the permitted clock >> skew. The clients can determine from the ticket issued by the KDC what >> the skew is and >> use that information to perform clock adjustments for future protocol >> exchanges. >> >> This approach is implemented in MIT Kerberos on MacOS X. It is not >> implemented on >> Windows because the credential cache implementations on Windows do not >> support >> it. >> > > It's better to change the skew so this is not an issue. > For managed machines this is true. For unmanaged machines or even machines joined to a domain that cannot reach the domain controllers at boot time due to firewalls, this is a much more difficult proposition. Another one of the issues with pre-Vista machines is that non-Administrator users don't have permission to change the time zone or trigger a clock sync.
Of course making sure that clocks are synchronized is preferable. However, there are circumstances where bending the rules makes sense. Jeffrey Altman Secure Endpoints Inc.
smime.p7s
Description: S/MIME Cryptographic Signature
________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
