Not sure - I'm not exactly an AFS subject matter expert and I haven't seen the AFS code that implements the key retrieval (from KeyFile) and token validation.
When I first started looking at MIT's krb524, this was the first problem we saw. [the 524 client setting the lifetimes incorrectly was the other, as apparently the resulting V4 ticket lifetimes are not communicated back to the client over the 524 wire protocol and the client is setting it based on 5 minute increments in the V4 ticket, not the CMU/AFS lifetime interpretation]. I noticed the kvno returned was "0", while the actual kvno for our afs principal was "1" (as seen via kadmin). Given the error and the observed behavior wrt kvno, the fix was rather straight forward. Perhaps your afs server uses different criteria for key retrieval. We're only now starting to roll out OpenAFS. Our observations were made with Transarc AFS, versios 3.x. Sorry I don't have a good answer for this. >>>>> "Ken" == Ken Hornstein <[EMAIL PROTECTED]> writes: >> There is also a bug in krb524d that does not set the kvno on the >> returned V4 ticket. Here's a patch: Ken> Interesting ... so what triggers this? I mean, it seems to work Ken> in normal circumstances ... Ken> --Ken ________________________________________________ Kerberos mailing list [EMAIL PROTECTED] http://mailman.mit.edu/mailman/listinfo/kerberos
