info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Re: Correct procedure to add a new enctype
8 views
Skip to first unread message
Greg Hudson
Dec 18, 2021, 1:13:28 PM12/18/21
to Dario García Díaz-Miguel, kerb...@mit.edu
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
> 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
0 new messages