Kerberos UDP packet size
Hi, I would like to get better understand of the Kerberos and how it works..or not. My user have problems to get kerberos tickets now, but after hour there are no problems. But last time user had problems I got the network trace and there I saw one reason for the problems: KRB_ERROR_RESPONSE_TOO_BIG. Jep jep, I just set the MaxPacketLength to "1" to force the kerberos to use TCP instead of UDP. Even I'm not 100 % sure that is needed, when reading the trace it seems that it tries to use TCP after this error. But let see does it change anything. But can someone clarify why the packet is growing higher than UDP frame allows? That user does not have so many group memberships at all so it seems to be not the reason. And of course the most strange thing is, that why it is working in some cases, but not after that. Perhaps, broken network component? -- Petri
October 6th, 2009 12:12am

Hi Petri, Thank you for posting here. I understand that you see the following in a network trace: KRB_ERR_RESPONSE_TOO_BIG: Response too big for UDP, retry with TCP This error indicates that the MaximumPacketSize setting for the domain controller the client is contacting is smaller than the setting on the client. Kerberos ticket requests are initially sent using UDP by RFC, however this behavior can be changed by configuring the MaxPacketSize registry value. This can be done on the domain controllers or the client. If the change is only made on the domain controllers you will see the error indicated in the problem description because the clients will still try UDP first. Default setting for MaxPacketSize is 1465 in Windows Server 2003. KB837361 Kerberos protocol registry entries and KDC configuration keys in Windows This error does not mean that fragmentation is occurring. It actually means that the client will automatically retry using TCP. This issue should be resolved by configuring both the client and the domain controller to the same MaxPacketSize registry value. To rule out any possibility of a UDP fragmentation problem the setting should be 1 for MaxPacketSize. Hope it helps. Best regards, Robinson Zhang TechNet Subscriber Support in forum
Free Windows Admin Tool Kit Click here and download it now
October 6th, 2009 5:11am

It still let two questions unanswered: - Why there are such a registry hack, if it is build for retrying by TCP? On the article there should be a comment, that: "this change is not needed when you see KRB_ERROR_RESPONSE_TOO_BIG, because windows can use TCP after this..". Only reason comes to my mind for this hack is the firewall. But there are no words about that. - What is increasing the packet size over the limit? Also, why to set MaxPacketSize to "1" and not "0" as Wista and W2008 have it? -- Petri
October 6th, 2009 10:04am

Hi Petri, Let's discusse question one by one. Regarding the registry key, I would like to let you know on my previous post I assumed you are using Windows Server 2003, which based on RFC 1510, the RFC states that UDP must be the first protocol that is tried. We modify the MaxPacketSize to "1" since it will be failed and we will get a TCP connection. However, RFC 4120 now obsoletes RFC 1510. By default, Windows Server 2008 and Windows Vista will try TCP first for Kerberos because the MaxPacketSize default is now 0. Hope it helps.
Free Windows Admin Tool Kit Click here and download it now
October 6th, 2009 1:05pm

Ok, the RFC is very good argument for the differences between W2008 and W2003. :) The reason I asked more details about the registry hack, is one of my user. He had problems to get tickets for the Exchange server. On the network trace I saw KRB_ERROR_RESPONSE_TOO_BIG message. After I set the MaxPacketSize to "1" the problem seems to go away. He get the tickets etc.. But if the original recovery method is working: change automatically from UDP to TCP when "TOO_BIG" message has received. Then why the registry key change the behavior? Actually I haven't done the full check yet, but the short tests looks like that :D -- Petri
October 6th, 2009 10:53pm

Hi Petri, Glad to hear the informaition is helpful. Regarding the latest question, I would like to share following informaiton with you:By default, the maximum size of datagram packets for which Windows Server 2003 uses UDP is 1,465 bytes. For Windows XP and for Windows 2000, this maximum is 2,000 bytes. Transmission Control Protocol (TCP) is used for any datagrampacket that is larger than this maximum. The maximum size of datagram packets for which UDP is used can be changed by modifying a registry key and value. (MaxPacketSize )By default, Kerberos uses connectionless UDP datagram packets. Depending on a variety of factors including security identifier (SID) history and group membership, some accounts will have larger Kerberos authentication packet sizes. Depending on the virtual private network (VPN) hardware configuration, these larger packets have to be fragmented when going through a VPN. The problem is caused by fragmentation of these large UDP Kerberos packets. Because UDP is a connectionless protocol, fragmented UDP packets will be dropped if they arrive at the destination out of order. If you change MaxPacketSize to a value of 1, you force the client to use TCP to send Kerberos traffic. Because TCP is connection oriented, it is a more stable connection. Even if the packets are dropped, the server will re-request the missing data packet.Sometimes, people do not want to use UDP to send Kerberos, so modify the registry key is a good choice. Hope it helps. Thanks.
Free Windows Admin Tool Kit Click here and download it now
October 7th, 2009 4:51am

Do I understood correctly you, that even I see on the Network monitoring trace - on the client side - Kerberos error: "KRB_ERROR_RESPONSE_TOO_BIG" I should not care about that. Just switch the UDP to the TCP, because of the client (WinXP) is not able to switch to TCP by some reason. But because I like to understand this problem, is there a method(s) to see that this packet fragmentation is the problem? -- Petri
October 7th, 2009 2:24pm

Hi Petri, I am afraid that I cannot fully understand the latest question. What you want to know is a methord(s) to check if the packet cause Exchange problem?Thanks.
Free Windows Admin Tool Kit Click here and download it now
October 8th, 2009 5:07am

Hi Petri,Could you please let me know the latest update?Thanks.
October 19th, 2009 11:25am

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

Other recent topics Other recent topics