When windows initiates a Kerberos authentication over user datagram packages (UDP), the following network communication occurs:
1. The Kerberos client requests a Ticket Granting Ticket (TGT) from the Domain Controller, respectively the Key Distribution Center (KDC).
2. The KDC replies to the client sending the TGT, if the authenticaction was successful.
3. The Kerberos client requests a service ticket from the Ticket Granting Service (TGS), containing the TGT which has been issued before (krbtgt/<DOMAIN>) and the service principal name (SPN) for the service being requested for access (<SERVICETYPE>/<FQDN of Server>).
4. The KDC replies to the client by sending the service ticket.
In some special cases, the network infrastructure may have problems with the UDP package, because it may be too big (exceeds the maximum UDP package size). As a result, the package will be fragmented and the KDC may not receive the package fragments in the correct order. As UDP is not a connection oriented protocol, this causes the KDC to fail processing the package. In this case, instead of replying to the client with a valid TGT, the KDC will respond with the following error message and the authentication process will be stopped:
KRB Error: KRB5KRB_ERR_RESPONSE_TOO_BIG (52)
In this scenario, windows logon may take a long time seeming to hang after entering the password and loading the user profile. Also, once logged in, accessing a new service (like connecting a share) may take a long time, when the service ticket for the requested service is not already available and needs to be requested first.
When Windows recognizes, that Kerberos over UDP fails, it will retry the authentication over TCP after a time out which is the reason behind the fact, that the authentication works finally but takes a while longer.
To avoid this behavior, Windows can be forced to use TCP directly instead of trying UDP first, by setting the following registry value:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\ Parameters] "MaxPacketSize"=dword:00000001
Please find additional information regarding this behavior in the MSKB244474 .