ktadd default enctype

[Nico Williams]

On Fri, Jun 05, 2015 at 11:11:12AM -0400, Greg Hudson wrote:
> > 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.

Oh, right, that's right, I forgot to mention that in my other post: the
Solaris kadmind uses a 1DES enctype as supported_enctypes for the old _1
kadm5 randkey_principal RPC.  The idea (this was like a decade ago, maybe
more) was that Solaris 8 and 9 used the _1 RPC and only supported 1DES,
while Solaris 10's ktadd client would always use the _3 RPC.

(I also confused create_principal with randkey_principal in my previous
post.  Sigh.  Need more coffee.)

So there you go.  You should just use the ktadd -e option.

> 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.

FYI (for JD), the difference between those two RPCs is mainly that one
takes a keysalt list (-e) and the other one doesn't.  But also the _3
RPCs were added much later, so Solaris 8 and 9 (for example) didn't
support them.

> 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).

That must be it, though why MD5 I don't know (or recall).

Thanks,

Nico
--