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 -- ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos