keytab, kvno, ktadd, and existing tickets

Chris Hecker checker at d6.com
Sat Jul 23 02:39:45 EDT 2011


Every time I ktadd to put a key in a keytab for a service, it increments 
the kvno.  I assume this is to provide some protection for compromised 
keytabs.  However, the existing keytabs to that service are now invalid 
(or, at least, fail the kvno check in the sample app if the client gets 
a new tkt).  I discovered this because I needed a second copy of a 
keytab for testing, and instead of copying the file, I just used kadmin 
to generate a new one.  It doesn't look like there's a kvno option to 
ktadd to specify it or have it not increment.

I guess I'm asking is the right thing here to just "don't do that"?  I 
should just make sure I have a copy of the keytab around at all times 
and copy it with cp instead of ktadd'ing to generate a new one?

Slightly related, krb5_cc_remove_cred doesn't seem to be implemented for 
file or memory caches, which makes kdeltkt not very useful.  Is this 
planned?  Not a big deal, just wondering.

Thanks,
Chris





More information about the Kerberos mailing list