The Impact of 2007 DST Changes on Kerberos/AD Logins

Here is a thought experiment I came up with to evaluate what will happen when users try to perform Active Directory logins after March 11 from client systems that have not been patched with the new Daylight Saving Time rules...

There are two scenarios to consider:

the local time on the unpatched client remains unadjusted, or the unpatched client is manually adjusted to correct time (but still with incorrect DST status). The latter should fail Kerberos, while the former will succeed.

Please double-check my logic to see if I have thought this through properly.

Scenario 1 - local time unadjusted:

User tries to login at 8:00am CDT (13:00 UTC). However, the unpatched client machine, even though it is set to automatically adjust for DST, is unaware of the new DST rules. It operates as if CST is still in effect, so the local system clock reads 7:00am.

When the user attempts the login, the computers at each end will translate their local clocks to UTC for the Kerberos processing, using whatever DST and time zone rules they think are in effect.

* The patched DC, with the new DST rules in place, will correctly add 5 hours to the value in its local clock, 8:00am, and come up with 13:00 UTC to use in Kerberos negotiations.

* The unpatched client, operating as if CST is still in effect, will incorrectly add 6 hours to the local clock value. But the local clock is an hour behind, reading 7:00am, so a UTC value of 13:00 will be calculated. The UTC values on each end match, and Kerberos is happy time-wise.

Scenario 2 - local time manually adjusted

All steps above are the same except for the last one.

The unpatched client, operating as if CST is still in effect, will incorrectly add 6 hours to the local clock value. But the local clock has been adjusted to read 8:00am, so the calculated UTC value will be 14:00.

Since this value is an hour off from the UTC calculated on the patched DC, Kerberos login will fail.

The moral of the story is this. An unpatched client can still do a Kerberos login, but only if the local clock has not been adjusted to show the correct time.

This adjustment would have to be done manually. If the machine is pulling time via NTP (which is passed in UTC), incorrect DST info will result in the local clock still being an hour behind.