On 12/16/21 4:38 AM, Dario García Díaz-Miguel wrote: > Currently we have two supported and default enctypes for tkt and tgs. > However, now we have an application that does not support our current > supported enctypes so we have to add a new enctype. > > Which is the correct procedure to add this enctype and to generate an > additional key for this enctype for each principal involved? > > I suppose that the enctype used will be the strongest one of the supported > enctype keys existing for that principal.
You need to ensure the following: * If the KDC has a permitted_enctypes setting, it needs to include the new enctype. * Server principals for the application must have a long-term key of only that enctype (use "-e enctype" when provisioning the keytab). * Clients must include that enctype in TGS requests they make. This is controlled by default_tgs_enctypes, or (in 1.18 and later) by permitted_enctypes if default_tgs_enctypes isn't set. It should not be necessary to change supported_enctypes. The krb5 libraries do not have a concept of relative enctype strength. Instead, they go by preference order when multiple enctypes are listed. So make sure to list the better ones first. For more information, see: https://web.mit.edu/kerberos/krb5-latest/doc/admin/enctypes.html ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
