This week will be a short tip about how to enable Kerberos logging. As per KB262177 (How to enable Kerberos event logging), Kerberos logging can be enabled by creating the following registry key:
- HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters
- Registry Value: LogLevel
Value Type: REG_DWORD
Value Data: 0x1
To disable it, simply delete the value or set it to 0. After enabling the logging you will receive Kerberos error event entries in the System event log. The setting will become effective immediately on Windows Server 2008, on Windows Vista, on Windows Server 2003, and on Windows XP. For Windows 2000, you must restart the computer.
When searching for Kerberos debug options, the registry keys “KerbDebugLevel” and “LogToFile” (also below the Lsa\Kerberos\Parameters hive) might come up. It is to my understanding that these do not have any effect on Windows 2008 and up. I asked this a while back on ActiveDir.org: Kerberos debug logging on Windows 2008
What events will be logged? The following is a short summary of the most common entries:
- KDC_ERR_PRINCIPAL_UNKNOWN: SPN not registered in AD, or service is being accessed under the wrong name
- KDC_ERR_PREAUTH_FAILED: can be safely ignored, is due to the way Kerberos works and how some Kerberos client compose their first request
- KRB_AP_ER_MODIFIED: bad error! someone is presenting a ticket for a service to a service while the ticket was encrypted with an account not responsible for the service. Wow what a line, bottom line: authentication is failing, no fallback to NTLM either!
- …
This MS document is a reference for the above (and other errors), contains many useful troubleshooting hints: Troubleshooting Kerberos Errors
12 Response to Kerberos Basic Troubleshooting: Tip 4
Ik vroeg me af of een ticket of bad ticket een negatieve invloed zou kunnen hebben op de windows-logon times?
Perhaps we can continue in english so that others can benefit the discussion as well?
Can you elaborate more? Obviously any kinds of failure might slow down the process. But it might depend if you feel it or not.
Sure, I was wondering if the tickets in general or a "corrupt" ticket could cause slow logontimes ?
I had a computer login on in 3.30min, i cleared the user and system tickets and all of the sudden it logs on in just 1min20sec. It could be coincidence but i was wondering if there is a know affiliation between the two ?
Also, is there a OS that has more problems with this than others? We run Windows 7 and Vista's.
I've never heard of corrupted logon tickets... Some tickets might not be handed out due to delegation errors, or SPN issues. Or your ticket might not contain all your group memberships if you're part of to many AD groups.
I don't think login times should be impacted by clearning tickets. I'd say logging off clears them anyway.
As far as OS is concerned I don't know of any version that has more problems with this than other versions...
I'd go for some googling regarding "debug slow logon" should give you some materiaal.
Well the slow logon-times are atm not a priority. Since today many users complain about not being able to access network location. As you said i read about the possibility that not all group memberships are loaded. But, this can only happen when you are in more than 1015 groups, the users i'm talking about are in +- 150 to 200 groups, well below the allowed limit.
When i use a whoami /groups i can see that not all ad groups were loaded. But some say that whoami is not realiable and that one should use "process explorer". Is i look there, i can see many security groups, problem is the info is not correct. It shows groups that the user once was a member of but isn't since a while now.
Strangely it seems to depends on de computer and not really on the groups. One user can log on to computer A and have no access, than log on to computer B and they have the correct access, go figure ...
So being new to kerberos tickets and how they work, its a bit of an overload today.
Hehe, I would definately invest "Kerberos token bloat" as that is what you are seeing I think.
If i'm not mistaken you can see this around 90-120 group memberships. Also keep in mind that memberhips are "expanded"! Nested groups also count. The 1015 limit is the "hard" limit indeed. This one only applies if you enlarge the default MaxToken size! By default the MaxToken size is about 12000 bytes I think which allows you to be in 90-120 groups approximately. You can tune this by setting the registry key for Max Token Size and it's max value is 65k orso. After setting it, then you'll be able to load over 120 group memberships. Keep in mind that setting it often requires a reboot. And you might have to set it client & server side. Also IIS might have to be tweaked to allow larger requests.
All in all it's a fairly complex topic which might require some testing and clear thinking... Don't just set the regkey on all machines and expect to be done with it...
Good luck!
So I'm not sure If I was clear but: yes you are below the hard limit of 1015 groups, but you are over the +- 120 groups which come with the default token size...
hmm I see, ok i'll have a little test tomorrow.
As to what tool to use, whoami or process explorer, which is the most realiable according to you?
Also let's say for argument sake that the kerberos-token is bloated. How come that the user does has the expected access on computer B and not on A ? As i would expect it to load the same token/tickets?
Does clearing the system-account from tokens (with a dosbox as system) resolve such an issue? Complex stuff indeed :)
I'm still spending a lot of time investigating this. I am wondering what is stored in the computer account token? What is the difference between the user token and the computer account token.And is there a difference between the computer token and the tokens of the system account in an elevated dosbox?
the difference is rather limited I think. Both hold the identitity and the group memberships. If you were to start a cmd prompt with psexec (as system), you will be able to list Kerberos tickets for the system. However you can also do this with the klist ticket from (an elevated) prompt: klist -li 0x3e7 de 0x3e7 is a specific number which Always matches the computer session.
what particular issue or you investigating right now?
for some reason, people can't access there networkshares. If i run a whoami /groups it becomes clear that not all seruritygroups are being loaded for some users (not all).
I have done networktraces with wireshark, investigated DNS problems (here there was an issue). One thing that does resolve this issue (once) is to rejoin the domain. But after the following reboot, it's back to square one ... .
Slowly running out of ideas by now
Without hands on this will be difficult to resolve. I'd say good luck with it... Perhaps you can ask you Active Directory / Desktop partner for assistance? They might have additional expertise who can help you tackle this problem.
Add Your Comment