How is ktadd *supposed* to figure out which enctype(s) to use?
I am seeing an issue where kadmin’s ktadd, if left to its own devices, will
generate a key with an encryption type that has nothing to do with the KDC’s
supported_enctype list and ktadd seems to completely ignore the local client’s
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-c
On Fri, Jun 05, 2015 at 07:24:06AM -0400, John Devitofranceschi wrote:
> How is ktadd *supposed* to figure out which enctype(s) to use?
Long ago I made Solaris' ktadd use the locally supported enctype list as
the default for ktadd, as if they'd been passed via the -e option (which
still works, nat
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
