[33626] in Kerberos
keytab, kvno, ktadd, and existing tickets
daemon@ATHENA.MIT.EDU (Chris Hecker)
Sat Jul 23 02:40:01 2011
Message-ID: <4E2A6CB1.2020003@d6.com>
Date: Fri, 22 Jul 2011 23:39:45 -0700
From: Chris Hecker <checker@d6.com>
MIME-Version: 1.0
To: "kerberos@mit.edu" <kerberos@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
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
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
