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