Vista Business SP1 does not show kerberos tickets in cached login session
Hi,Background:- Vista Business SP1 with all recent patches- 400+ workstations- Windows 2003 DomainWe have found that randomly some of ourVista clients will not have any kerberos tickets when the user logs in. We have verified the lack of kerberos tickets using kerberos tray and klist. In these cases, when the user logs out and back in the workstation, the problem is fixed, but this doesn't address the issue or explain why it happens in the first place.We have managed to replicate the problem behavior by disconnecting the network connection to a test Vista workstation. Then logged in the workstation(while disconnected from the network) in a cached domain session. Once logged in the cached session, we reconnect the network cable and have access to all network resources, i.e. drive shares, Outlook/Exchange etc. The problem is though, that when we check kerbtray or klist, no kerberos tickets are present. It seems that Vista has fallen back to NTLM and isnot attempting Kerberos authentication. From what I understand, this is not the expected behavior as the OS should request the kerberos tickets and have the KDC provide them.Any thoughts as to what we are missing here?This issue is causing us some grief as certain applications of ours only do kerberos authentication and there is no NTLM auth backup available for these apps.Thank you!Ben
February 26th, 2009 10:57am

Hi, Thank you for posting. I suspect this may be related to Fast Logon feature: Description of the Windows XP Professional Fast Logon Optimization feature http://support.microsoft.com/kb/305293 (This setting also exists in Windows Vista's local policy.) Also, please also check the following: 1. Regarding "Vista clients will not have any Kerberos tickets when the user logs in", we would like to know: a. Did you check the Kerberos tickets once after the user logon? b. How does the computer connect to the domain? Via wireless? c. How many Windows Vista clients might this issue occur on? All Windows Vista computers there, or just some specific clients? 2. When the issue occurs, please do not log off. Instead, try to access an file server in the domain (please ensure the share has not yet been accessed in this session). After connecting the share, please check whether the Kerberos tickets are correctly created. Thanks! Nicholas Li - MSFT
Free Windows Admin Tool Kit Click here and download it now
February 27th, 2009 2:50pm

Hi Nicholas, Thank you very much for your reply here. I appologize for replying so late. Other pressing issues took precedence and we put aside this problem to revisit later. I will have to explore the fast logon optimization feature to see if it will help. To provide some details on your questions: 1. a. Did you check the Kerberos tickets once after the user logon? Yes, there are no kerberos tickets whatsoever, no TGT either. 1. b. through wired 100mb ethernet connections - I should not that we have a VOIP phone that the PC connects to first, before connecting to the POE Cisco switch 1. c. We have well over 400 Vista SP1 workstations all running the same identical OS image, missing kerberos tickets have happened to random machines at different times - it will not always happen, and not to all workstations, but it can happen randomly. 2. We have tried this, we can access a file server, Outlook/Exchange 2007 mailboxes without any problems, but sill no Kerberos tickets or TGT - because the OS is using NTLMv2 rather than Kerberos - tickets will never appear (we check ticket availability with kerbtray) Some additional interesting information: We believe the issue is related to the way our workstations come back from sleep. This issue ONLY happens when workstations resume from sleep (we have disabled Hybrid sleep). GPO dictates our workstations go to sleep after 30 minutes. This issue only happens at random when workstations resume from sleep. Now, looking at the System event logs, we see warning entries for eventID 1003: Event ID 1003 Source DHCP Type Warning Description Your computer was not able to renew its address from the network (from the DHCP Server) for the Network Card with network address <MAC address>. The following error occurred: <error description>. Your computer will continue to try and obtain an address on its own from the network address (DHCP) server." We have been in contact with our motherboard manufacturer (Intel) regarding why their on board NIC takes upto 10 - 30 seconds to obtain an IP address from our DHCP server after the machine wakes from sleep. We believe this in combination with Vista not re-requesting for a TGT and kerberos tickets due to the delay of obtaining the IP address. The problem is that we cannot reproduce the issue - it happens random, but daily to about 1% of our workstations (say about 4 out of 400 pcs each day). If there is a way to force Vista to re-request a TGT after logon, it would resolve our problem. Alternatively if I could find a way to delay the Vista logon process until kerberos handshake can take place, that would help as well. Any help would be much appreciated!
April 30th, 2009 6:13pm

After a lot of testing, I'm convinced that this has to be a bug in Vista SP1. On a daily basis, 1% of our workstations fail to perform Kerberos authentication. The only fix we have found is to have the user log out of the workstation and log back in. This always works because the failed Kerberos Authentication only happens when PCs resume from sleep (the 1% of time that it does happen). 1% wouldn't seem like much, but on average, that's about 4 PCs a day that report this.Is any one else experiencing anything similar to this or does MS have anything to indicate if this could be a bug in the Vista client?
Free Windows Admin Tool Kit Click here and download it now
June 15th, 2009 8:57pm

Instead of logging out and back in, have the user lock the workstation and then unlock it. This causes the workstation to reauthenticate with a domain controller (if it can) without the disruption and time of having to close all the user's programs.I've run into this problem with remote users that VPN in. When they sleep or hibernate, the VPN connection is dropped. When they wake up and unlock the workstation, the VPN is still down and no TGT can be obtained. Locking and unlocking the workstation after reconnecting the VPN causes Windows to reauthenticate with the domain controller. My guess is that because unlocking the workstation before the VPN has reconnected causes Windows to authenticate the user with the cached login credentials, not through Kerberos, Windows then has it in its head that a domain controller is not available and therefore makes no attempt to obtain a TGT.
October 14th, 2009 9:08am

Thanks ScottEnglish. I recall having read the unlocking/locking process somewhere and had tried it. In the past it hadn't worked for us and users still needed to fully log out and log back in. Interestingly, the behaviour has changed slightly since we have pushed out Vista SP2 to our desktops. TGT is still not granted when this happens, but when users try to authenticate against the proxy server, they will just be able to provide credentials for that one IE session. The Kerberos dll files have certainly changed from SP1 to SP2. I still believe this is a bug on the Vista/7? client kerberos libraries that given some fluke timing when coming back from sleep, will fail to send a proper GUID to the DC in order to obtain a TGT. To summarize this issue for us still: - On a daily basis less than 1% of our users cannot authenticate against our squid proxy server which only does Kerberos auth. 1. Occurs daily to less than 1% of users (i.e. 2 or 3 users report it) 2. It only happens when coming back from sleep 3. Logging off and back in fixes the issue 4. We're living with it, but really would like to have it resolved.
Free Windows Admin Tool Kit Click here and download it now
October 14th, 2009 6:08pm

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics