[39034] in Kerberos
Re: Correct procedure to add a new enctype
daemon@ATHENA.MIT.EDU (Greg Hudson)
Sat Dec 18 13:42:00 2021
To: =?UTF-8?Q?Dario_Garc=c3=ada_D=c3=adaz-Miguel?= <dgdiaz@gmv.com>,
"kerberos@mit.edu" <kerberos@mit.edu>
From: Greg Hudson <ghudson@mit.edu>
Message-ID: <8ae020e6-5bfd-a3d8-e811-8543d00fdf31@mit.edu>
Date: Sat, 18 Dec 2021 13:13:09 -0500
MIME-Version: 1.0
In-Reply-To: <a5af252ff3a249a8a9176e17971a46e1@gmv.com>
Content-Language: en-US
Content-Type: text/plain; charset="windows-1252"
Errors-To: kerberos-bounces@mit.edu
Content-Transfer-Encoding: 8bit
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
