First published on CloudBlogs on May, 24 2007
One of the cool things about this job is the way we get to trail blaze new issues as they happen and before any solution or workaround is in sight. We’re the pioneers in a way. This is one example.
We’ve had a few customer’s recently mention that they had seen an odd behavior from their Vista clients. When their environment fit certain criteria they found that the Vista workstations could not successfully log into the domain. Those criteria were: logging in across a trust (where user account was in one domain, computer account in another), the workstation was Windows Vista (didn’t occur on other operating system clients of the same domains), and the users account properties in AD were set to “do not require Kerberos preauthentication”. Removing the “do not require Kerberos preauthentication” check box from the user properties would make the problem magically disappear.
So, when a user tried to logon to that “accounts” domain in this manner they would fail to logon successfully and would instead get a message with a white X in a red circle that said “There is a time and/or date difference between the client and server”. This would occur when no significant time difference existed. Keep in mind that the allowed skew (difference in time) here is by default 300 seconds, or 5 minutes.
At first I thought this was simply a result of some uniqueness in their environment, like a custom password filter, since we have seen some surprising behaviors from custom code like that in the past. However, all of our testing resulted in that not being it.
Next, I explored the thought that perhaps this has to do with a new feature in Windows Vista. Specifically, the fact that Vista clients do not automatically send their pre authentication data to the KDC during the initial TGT request traffic (or AS_REQ for your die-hard Kerberos folks out there). This is intentionally done as a method to negotiate using the highest level of encryption that Vista can support to encrypt that preauth data with. Namely, Advanced Encryption Standard (AES). The way this goes is that the DC responds with an AS_REP with the KDC_ERR_PREAUTH_REQUIRED error as well as a list of the encryption methods which the DC supports. For Longhorn DCs the response will also include AES, so when the Vista workstation sees that it resends the AS_REQ-with preauthentication data this time!- but it encrypts it using AES which it now knows the KDC supports. For non-Longhorn DCs it simply resends the AS_REQ encrypted using one of the encryption methods supported by that responding DC.
Sadly, that was not the origin of this little gem of a problem.
Then we discovered that we could reproduce this in our own test environments. Quell surprise that was. This led to a few other revelations, like there is one other unique circumstance needed, in addition to those we already knew about. Namely, if you have a later version of KdcSvc.dll on your Server 2003 domain controller then you will not see this behavior. We found that a security update, and Server 2003 Service Pack 2 includes a newer version of KdcSvc.dll as well, and that also prevents this issue.
So, what do you do if you see this in your environment?
· First, check the time on workstation and server with Mark One Eyeball to make sure that there isn’t in fact any time or date difference.
· Second, makes sure this only occurs for Vista clients.
· Third, verify that the “do not require Kerberos preauthentication” check box is set on the user experiencing the problem, and that deselecting it and logging on as that user makes issue go away.
· Finally, check the version of KdcSvc.dll on the accounts domain (domain where the user account resides). You can do this by going to StartàRunàMSINFO32. Once System Information is open, go to Software EnvironmentàLoaded Modules and look for KDCSVC.DLL.
If you have this version or earlier on your “accounts” domain domain controllers then we would expect you to see the problem occur in this scenario:
kdcsvc 5.2.3790.1830 (srv03_sp1_rtm.050324-1447) 213.50 KB (218,624 bytes) 5/14/2007 5:22 PM Microsoft Corporation c:windowssystem32kdcsvc.dll
If you have the security update below, or the SP2 version of the file then you should not see this issue:
Security update For Windows Server 2003 KB899587
OR
kdcsvc 5.2.3790.3959 (srv03_sp2_rtm.070216-1710) 214.50 KB (219,648 bytes) 5/11/2007 2:21 PM Microsoft Corporation c:windowssystem32kdcsvc.dll
Solution then is to update your accounts domain DCs with the latest version of kdcsvc.dll.
***Note: The time and date above are not indicative of version and "newness" of the file. Only the file version and "tree" info (such as 5.2.3790.3959 (srv03_sp2_rtm.070216-1710)) are the valid things to look at. Thanks to my colleague Robert Stampfer in Germany for pointing that out.***
In the off chance that the customers who experienced this issue in their environment see this blog post I’d like to give a big thank you for all of your patience on this issue.
Stay tuned for the next post folks-it’s another unique Vista issue and just as interesting!
