On Mon, 10 Nov 2014 14:24:49 +0100 Volkmar Glauche <[email protected]> wrote:
> I've never used kaserver/kerberos4, but maybe I followed installation > guidelines that still had kaserver in mind and proposed kvno=0. Would > bumping the kvno affect existing tokens/Keyfiles that are still > relying on kvno=0? If so, I'll have to postpone keytab installation > until I find a maintenance time slot. For specifically rxkad.keytab (i.e. non-DES) processing, we mostly ignore the kvno for incoming connections, so this shouldn't break anything and you should be okay (checking the kvno only changes the error we return if we can't find a working key). But if you want to be more careful, just add the same key with a new kvno, and don't remove the existing kvno 0 entries. And for anyone reading this text in the future: this behavior notably does _not_ apply to KeyFile processing and relying on this behavior outside of specific one-off situations like this is probably a bad idea. I'm still a little confused as to how you got the 0 kvno entry, though. Does the KDC say the service princ has a kvno of 0? If not, you should just be using the kvno the KDC says. -- Andrew Deason [email protected] _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
