[17038] in Kerberos_V5_Development
Re: Multiple ETYPE-INFO-ENTRY with same etype but different salts
daemon@ATHENA.MIT.EDU (Weijun Wang)
Sun Jul 17 20:13:26 2011
In-Reply-To: <4E22ED18.9090603@ufl.edu>
Mime-Version: 1.0 (Apple Message framework v1084)
Message-Id: <48598D5D-17A8-45F1-926B-04A60AEB55C8@oracle.com>
From: Weijun Wang <weijun.wang@oracle.com>
Date: Mon, 18 Jul 2011 08:12:59 +0800
To: "Martin B. Smith" <smithmb@ufl.edu>
Cc: krbdev@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
On Jul 17, 2011, at 10:09 PM, Martin B. Smith wrote:
> 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 and
>>> > 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 been a severe hold-up for us in terms of upgrading various kerberized clients (specifically Java).
>
> Doesn't removing the offending enctype that is putting bad salts in the KDB records just mask a bug with that enctype? We have brand new principals that are affected by this issue every day, so it seems like one of the enctypes is actually broken if it's generating invalid salt values.
>
> Our current list of supported enctype is:
>
> supported_enctypes = des-hmac-sha1:normal des-cbc-md5:normal 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. How would you re-order that list to fix the problem? Would you just remove the two latter des- entries?
Hi Martin
Do you need to keep the "des-cbc-crc:v4 des-cbc-crc:afs3" entries there?
This is not a problem of re-ordering. Your ETYPE-INFO already places the entry with the wrong salt at the end of the list. The problem here is that Java insists on reading a non-empty and non-missing salt from the list. Therefore, unless you completely remove the wrong entry (or, manage to insert an entry with the correct salt before it), Java will always use the wrong salt.
I think the bug here is that even if some-etype:v4 exists in the supported_enctypes, the KDC should not generate an ETYPE-INFO-ENTRY for it in a response to a v5 AS-REQ.
Thanks
Max
>
> Thanks again,
> --
> Martin B. Smith
> smithmb@ufl.edu - (352) 273-1374
> CNS/Open Systems Group
> University of Florida
>
> _______________________________________________
> krbdev mailing list krbdev@mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
