On 06/05/2015 07:24 AM, John Devitofranceschi wrote: > How is ktadd *supposed* to figure out which enctype(s) to use?
In the absence of the optional keysaltlist parameter, it's supposed to be determined by supported_enctypes on the KDC. > But when we run ktadd the resulting keytab’s key has des-cbc-md5 > > The client is an Oracle Linux with 1.6.1 krb5 client software. > > Also, the KDC is using Sun Solaris 10 Kerberos software (not MIT). The short answer: Solaris implements transitional logic which isn't really compatible with the MIT kadmin client for this operation. We have a workaround in MIT krb5 release 1.13. kadmin's ktadd invokes a chrand RPC in order to get the new keys for the keytab. There are two versions of this RPC, chrand_principal and chrand_principal3. The former accepts a principal name and optionally returns a list of keys; the latter also accepts an optional keysalt list. Prior to release 1.13, the MIT krb5 behavior is to invoke chrand_principal3 if a keysalt list is specified, and chrand_principal otherwise, so that typical randomize-key requests work against old kadmind servers without an extra round trip. In Solaris Kerberos, however, the client behavior is to always invoke chrand_principal3 and then fall back to chrand_principal if that fails. Furthermore, the kadmind server assumes that a chrand_principal request must come from an old client, and picks a different keysalt list (which I guess is just des-cbc-md5:normal). MIT krb5 1.13 matches the Solaris Kerberos client behavior and should not display the odd behavior you're seeing. ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos