more ldap concerns

[Henry B. Hotz]

UMICH contributed a patch to do just that not long ago.  Has it not  
been integrated?

I'm concerned that there seem to be some pretty-visible things  
popping up that are back-end dependent.

On Jun 7, 2006, at 4:57 PM, krbdev-request at mit.edu wrote:

> Date: Wed, 7 Jun 2006 18:57:42 -0500
> From: Nicolas Williams <Nicolas.Williams at Sun.COM>
> Subject: Re: more ldap concerns
> To: Jeffrey Hutzelman <jhutz at cmu.edu>
> Cc: Ken Raeburn <raeburn at mit.edu>, MIT Kerberos Dev List
> 	<krbdev at mit.edu>
> Message-ID: <20060607235742.GX5688 at binky.Central.Sun.COM>
> Content-Type: text/plain; charset=us-ascii
>
> On Wed, Jun 07, 2006 at 07:46:57PM -0400, Jeffrey Hutzelman wrote:
>>> Why are the old keys still around?
>>
>> Because the TGS is an unusual service, in that instead of finding its
>> service keys in a keytab, it reads them directly from the KDB.   
>> So, if
>> changing the TGS's key in the KDB caused the old keys to go away, it
>> wouldn't be able to find them any more, and you'd have just  
>> invalidated
>> every outstanding TGT.
>>
>> Of course, if invalidating previously-issued TGT's is your goal,  
>> then you
>> should remove the old keys explicitly.
>
> Agreed.  But UI-wise this is no good.
>
> There should be a note about the old keys being retained even though
> -keepold wasn't used and an option should be provided to destroy  
> the old
> keys anyways...
>
> ...OR there should be a prompt if -keepold wasn't used when  
> randkeying a
> krbtgt principal.
>
> Or something like that.
>
> Nico
> -- 

------------------------------------------------------------------------ 
----
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz at jpl.nasa.gov, or hbhotz at oxy.edu