more ldap concerns

[Jeffrey Hutzelman]

On Wednesday, June 07, 2006 06:08:07 PM -0500 Will Fiveash 
<William.Fiveash at sun.com> wrote:

> and when I do:
>
> kadmin.local -q 'cpw -randkey krbtgt/ACME.COM'
> kadmin.local -q 'cpw -randkey krbtgt/ACME.COM'
>
> I see:
>
> kadmin.local -q 'getprinc krbtgt/ACME.COM'
> Authenticating as principal willf/admin at ACME.COM with password.
> Principal: krbtgt/ACME.COM at ACME.COM
> Expiration date: [never]
> Last password change: Wed Jun 07 18:05:56 CDT 2006
> Password expiration date: [none]
> Maximum ticket life: 1 day 00:00:00
> Maximum renewable life: 7 days 00:00:00
> Last modified: Wed Jun 07 18:05:56 CDT 2006 (cn=directory
> manager at ACME.COM) Last successful authentication: [never]
> Last failed authentication: [never]
> Failed password attempts: 0
> Number of keys: 5
> Key: vno 1, Triple DES cbc mode with HMAC/sha1, no salt
> Key: vno 2, Triple DES cbc mode with HMAC/sha1, no salt
> Key: vno 2, DES cbc mode with CRC-32, no salt
> Key: vno 3, Triple DES cbc mode with HMAC/sha1, no salt
> Key: vno 3, DES cbc mode with CRC-32, no salt
> Attributes:
> Policy: [none]
>
> 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.


-- Jeff