[17036] in Kerberos_V5_Development
Re: Multiple ETYPE-INFO-ENTRY with same etype but different salts
daemon@ATHENA.MIT.EDU (Martin B. Smith)
Sun Jul 17 10:09:33 2011
Message-ID: <4E22ED18.9090603@ufl.edu>
Date: Sun, 17 Jul 2011 10:09:28 -0400
From: "Martin B. Smith" <smithmb@ufl.edu>
MIME-Version: 1.0
To: Greg Hudson <ghudson@mit.edu>
In-Reply-To: <4E228CAA.1020809@oracle.com>
Cc: Weijun Wang <weijun.wang@oracle.com>, krbdev@mit.edu
Content-Type: multipart/mixed; boundary="===============0736573516=="
Errors-To: krbdev-bounces@mit.edu
This is a cryptographically signed message in MIME format.
--===============0736573516==
Content-Type: multipart/signed; protocol="application/pkcs7-signature";
micalg=sha1; boundary="------------ms060301070608000208000109"
This is a cryptographically signed message in MIME format.
--------------ms060301070608000208000109
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
On 07/17/2011 03:18 AM, Weijun Wang wrote:
>> In this case, the etype-info2 entries are determined by the keys in
>> > the KDB records. The KDC administrator could change the
>> > supported_enctypes variable to include only one des-cbc-crc entry a=
nd
>> > then have the affected users change their passwords.
> The customer has tens of thousands of existing accounts and cannot do a=
> simple password reset. Is it possible to remove the ETYPE-INFO-ENTRY
> with only realm as salt by reconfigure the KDC? Or, is there a tool to
> clean up the KDC records automatically?
>
> Thanks
> Max
Hi Greg & all,
First of all, thank you *very* much for your help with this issue. It's=20
been a severe hold-up for us in terms of upgrading various kerberized=20
clients (specifically Java).
Doesn't removing the offending enctype that is putting bad salts in the=20
KDB records just mask a bug with that enctype? We have brand new=20
principals that are affected by this issue every day, so it seems like=20
one of the enctypes is actually broken if it's generating invalid salt=20
values.
Our current list of supported enctype is:
supported_enctypes =3D des-hmac-sha1:normal des-cbc-md5:normal=20
des-cbc-crc:v4 des-cbc-crc:afs3 des3-hmac-sha1:normal arcfour-hmac:normal=
As you can see, I think we *are* already listing 'normal' ones first.=20
How would you re-order that list to fix the problem? Would you just=20
remove the two latter des- entries?
Thanks again,
--=20
Martin B. Smith
smithmb@ufl.edu - (352) 273-1374
CNS/Open Systems Group
University of Florida
--------------ms060301070608000208000109--
--===============0736573516==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
--===============0736573516==--
