There is a bug in MIT's krb5 implementation that when preauth is needed, the KRB-ERROR message as the initial response to a AS-REQ without preauth info might contain multiple ETYPE-INFO(2)-ENTRYs with the same etype but different salt in the padata ETYPE-INFO(2). Furthermore, if krb4 is enabled, one of the salt might be different from the default krb5 salt.

We have a customer who PA-ETYPE-INFO contains these entries. Note that the customer has not made any special configuration to the KDC.

   Entry 1: des-cbc-null, no salt
   Entry 2: des-cbc-null, salt = ""
   Entry 3: des-cbc-null, salt = "REALM"

Before 6959292, we simply read the first entry, since there is no salt here, the default one is used snd it's good. After that, we read all entries and find one salt which is neither empty nor missing, and the wrong salt in Entry 3 is used.

The reason for 6858292 is because we are seeing this PA-ETYPE-INFO on Windows:

   Entry 1: rc4-hmac, no salt
   Entry 2: des-cbc-null, salt = "REALMuser"

In JDK 6, we do not save different salts for different etypes, and we only save one. So we read all entries and choose a salt which is neither missing nor empty.

The suggested fix is:

On JDK 7 and 8, we already save different salts for different etypes, so we should only save the salt of the first apppearance for the etype. This is consistent with the MIT krb5 and Heimdal behavior.

On JDK 6 (or earlier), we still save only one salt, and --
1. For duplicated etypes, we save the first appearance
2. For different etypes, we save the non-empty and non-missing one