asked on Kerberos Failing on Workstations on Domain
Hello, and thanks in advance for any help you can provide me.
We have a Domain with Active Directory. There are about 3,000 client PC's using Windows XP Pro and about 5-7 Domain Controllers Using Windows Server 2003 . We are encountering the following problem with only a handful of computers right now, but the issue seems to be growing slowly. Some users in our field offices connect to a Sharepoint website to view reports that are specific to their area. Sharepoint decides what view they see by their logon credentials. When accessing this site on PC #1 - User #1 is unable to view the report - it is basically not giving them any options to select for specific weeks, etc. The page itself does come up, but the options to make selections on that page do not.
Now if this same user #1 goes to PC #2 - they can get to the page and view the report without any issue. So this tells me the issue could be with the PC itself.
User #2 logs into PC#1 - goes to the site, and has no issues...
We ran NetDiag on the PC while it was logged in under these two different user ID's. The resulting log files were identical except for the following two tests:
We then ran a NetDiag on PC #1 while logged in under User #1 ID and get the following:
Trust relationship test. . . . . . : Passed
Secure channel for domain '(DOMAIN NAME)' is to '(DOMAIN CONTROLLER #1.DOMAIN.COM)'.
Kerberos test. . . . . . . . . . . : Failed
[FATAL] Cannot get ticket cache from Kerberos.
The error occurred was: (null)
We then log into same PC #1 with user #2 and run NetDiag on the PC:
Trust relationship test. . . . . . : Passed
Secure channel for domain '(DOMAIN NAME)' is to '(DOMAIN CONTROLLER #2.DOMAIN.COM)'.
Kerberos test. . . . . . . . . . . : Passed
So they are authenticating the trust relationship with two different Controllers (domain controller #1 and #2), and User #1 is getting Kerberos Failures.
Most of the time re-adding the PC to the Domain fixes the issue - but now I am getting more calls with this issue and even have a PC that has repeat behaivior after re-adding to the domain about a month ago. To make things even more interesting, it is only associated with this particular web site in our Sharepoint Environment... all other internal websites and/or applications are working fine when the user needs to authenticate (at least as far as I can tell)
A few questions:
1. What is causing this kerberos failure for one user, but not another on the same PC?
2. Why is it only linked to that specific site?
3. Is there any other test that I can do to help troubleshoot this issue?
so far we tried installing the Windows Resource Tools(kerbtray) to see if kerberos is running but no luck, it doesnt list any tickets. in some PCs kerberos works with one user but not on another one. when rejoining the PC to the domain, it fixes the problem.
but we found other PCs that when kerberos doesnt work on anybody... rejoining to the domain does not fix the issue.
how do we fix the kerberos issue? what causes kerberos to stop working on some users?
Thanks again for any information! we appreciate your help
We have a Domain with Active Directory. There are about 3,000 client PC's using Windows XP Pro and about 5-7 Domain Controllers Using Windows Server 2003 . We are encountering the following problem with only a handful of computers right now, but the issue seems to be growing slowly. Some users in our field offices connect to a Sharepoint website to view reports that are specific to their area. Sharepoint decides what view they see by their logon credentials. When accessing this site on PC #1 - User #1 is unable to view the report - it is basically not giving them any options to select for specific weeks, etc. The page itself does come up, but the options to make selections on that page do not.
Now if this same user #1 goes to PC #2 - they can get to the page and view the report without any issue. So this tells me the issue could be with the PC itself.
User #2 logs into PC#1 - goes to the site, and has no issues...
We ran NetDiag on the PC while it was logged in under these two different user ID's. The resulting log files were identical except for the following two tests:
We then ran a NetDiag on PC #1 while logged in under User #1 ID and get the following:
Trust relationship test. . . . . . : Passed
Secure channel for domain '(DOMAIN NAME)' is to '(DOMAIN CONTROLLER #1.DOMAIN.COM)'.
Kerberos test. . . . . . . . . . . : Failed
[FATAL] Cannot get ticket cache from Kerberos.
The error occurred was: (null)
We then log into same PC #1 with user #2 and run NetDiag on the PC:
Trust relationship test. . . . . . : Passed
Secure channel for domain '(DOMAIN NAME)' is to '(DOMAIN CONTROLLER #2.DOMAIN.COM)'.
Kerberos test. . . . . . . . . . . : Passed
So they are authenticating the trust relationship with two different Controllers (domain controller #1 and #2), and User #1 is getting Kerberos Failures.
Most of the time re-adding the PC to the Domain fixes the issue - but now I am getting more calls with this issue and even have a PC that has repeat behaivior after re-adding to the domain about a month ago. To make things even more interesting, it is only associated with this particular web site in our Sharepoint Environment... all other internal websites and/or applications are working fine when the user needs to authenticate (at least as far as I can tell)
A few questions:
1. What is causing this kerberos failure for one user, but not another on the same PC?
2. Why is it only linked to that specific site?
3. Is there any other test that I can do to help troubleshoot this issue?
so far we tried installing the Windows Resource Tools(kerbtray) to see if kerberos is running but no luck, it doesnt list any tickets. in some PCs kerberos works with one user but not on another one. when rejoining the PC to the domain, it fixes the problem.
but we found other PCs that when kerberos doesnt work on anybody... rejoining to the domain does not fix the issue.
how do we fix the kerberos issue? what causes kerberos to stop working on some users?
Thanks again for any information! we appreciate your help
Microsoft Legacy OSWindows XPActive Directory
Last Comment
cwalter77
Hi, it's me again.
Have you looked into if it is a duplicate SPN issue:
http://support.microsoft.c
There is a related post here:
http://www.minasi.com/forum/topic.asp?TOPIC_ID=19901
Have you looked into if it is a duplicate SPN issue:
http://support.microsoft.c
There is a related post here:
http://www.minasi.com/forum/topic.asp?TOPIC_ID=19901
I should mention, I find Method 2 in the M$ article to be the easiest.
ASKER
We will check it out and post the results. Thanks!
ASKER
Changing the setting in Group Policy for cachedlogons from 10 to 1 works on the Desktop workstations. We are not implementing this on laptops though for the obvious reasons.
Our server team is still researching the servers as suggested by Pber above.
Our server team is still researching the servers as suggested by Pber above.
ASKER
Unfortunately over the past few days, we are starting to get repeat offenders even with the registry key changed. I guess we are back to the drawing board....
I couldn't figure out why M$ suggest that setting, it didn't seem like it would work on your problem. Sorry it didn't solve it though.
Any success on the SPN front?
I'm not sure if this is related, but I'll mention it as we've had Kerberos issues in certain scenarios. By default, when a user logs on they it will attempt a Kerberos negotiation using the UDP protocol first. The problem with UDP is if the packets fragement and get received in the wrong order, the Kerberos negotiation fail. It drops down to NTLM authentication and sometimes logons take a long time because of retries.
We've seen this with specific users with large number of group memberships resulting a tokens being larger than the default MTU size of 1500 bytes. This might explain some of your results that some users work and other don't on the same machine. We've also seen this with users authenticating across firewalls.
We fixed our issues like this by forcing Kerberos to use TCP instead of UDP. This M$ article goes into some background and how to change it.
http://support.microsoft.c
The nice thing, is you can change this setting on a few machines and test. We ultimately went the GPO path after we proved our results. I believe in Vista and 2008, they implemented a newer RFC spec for Kerberos which already forces Kerberos to use TCP.
Any success on the SPN front?
I'm not sure if this is related, but I'll mention it as we've had Kerberos issues in certain scenarios. By default, when a user logs on they it will attempt a Kerberos negotiation using the UDP protocol first. The problem with UDP is if the packets fragement and get received in the wrong order, the Kerberos negotiation fail. It drops down to NTLM authentication and sometimes logons take a long time because of retries.
We've seen this with specific users with large number of group memberships resulting a tokens being larger than the default MTU size of 1500 bytes. This might explain some of your results that some users work and other don't on the same machine. We've also seen this with users authenticating across firewalls.
We fixed our issues like this by forcing Kerberos to use TCP instead of UDP. This M$ article goes into some background and how to change it.
http://support.microsoft.c
The nice thing, is you can change this setting on a few machines and test. We ultimately went the GPO path after we proved our results. I believe in Vista and 2008, they implemented a newer RFC spec for Kerberos which already forces Kerberos to use TCP.
ASKER CERTIFIED SOLUTION
THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
This is Microsoft's suggestion.
1. Change the registry key KEY_LOCAL_MACHINE\SOFTWARE
2. Reboot and log in as the user
Some background on this setting:
Determines how many user account entries Windows saves in the logon cache on the local computer. Windows saves the user account data that is used to log on to the computer so the data can be used if the user's domain controller is unavailable.
If the value of this entry is 0, Windows does not save any user account data in the logon cache. In that case, if the user's domain controller is not available and a user tries to log on to a computer that does not have the user's account information, Windows displays the following message:
"The system cannot log you on now because the domain <Domain-name> is not available."
I will post whether or not this fully fixed our issue.