Server 2008 and Windows Vista: Encryption Better Together

Tim Springston — Fri, 02 Nov 2007 15:00:00 GMT

A while back I did a blog post about some problems that were seen with people testing Windows Vista and then “rolling back” to Windows XP and some problems that could be seen when using the same computer object (also known as account) in AD. If you didn’t get a chance to read it here’s the post. What that scenario highlighted was the added level of encryption, by way of leaving behind a little of the supporting infrastructure in the msds-supported-encryptiontypes attribute value. In this post we’re going to talk about the Big Picture of the new authentication encryption available and a few things to keep in mind....(read more)

All The Logging In The World

Tim Springston — Mon, 08 Oct 2007 19:40:00 GMT

There’s normal troubleshooting and then there’s the stuff you do when the basic troubleshooting doesn’t get things resolved. Normal troubleshooting can be things like selecting “last known good” on a reboot after installing a new driver and having a blue screen. Or perhaps uninstalling and then reinstalling an application, or altering settings for the application or operating system to alleviate a problem. Sometimes we have to dig in and find out more. Many admins out there in the world live that every day. Which is why we add methods to find out more into our products. This post is all about listing all of the data gathering methods that a Directory Services person may ever need to know. Since there are so many it will be difficult to organize well in one uber post but I’m going to put out here for you all anyway, disorganized or not....(read more)

Vista Issue: Time Skew Error When Logging on Across a Trust

Tim Springston — Fri, 25 May 2007 01:53:00 GMT

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:\windows\system32\kdcsvc.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

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:\windows\system32\kdcsvc.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!

Active Directory Blog : Vista, Kerberos

Server 2008 and Windows Vista: Encryption Better Together

All The Logging In The World

Vista Issue: Time Skew Error When Logging on Across a Trust