On Feb 26, 2010, at 14:03 , Jonathan Nilsson wrote:
On Fri, Feb 26, 2010 at 10:44, Brandon S. Allbery KF8NH <[email protected] > wrote:On Feb 26, 2010, at 13:24 , Jonathan Nilsson wrote: [09:57 r...@afs1 ~]# kvno -c /tmp/krb5cc_0 afs [email protected]: kvno = 2 [09:57 r...@afs1 ~]# kvno -c /tmp/krb5cc_0 afs/mycell.edu afs/[email protected]: kvno = 2You put both of these in the KeyFile? With the same kvno? This will break, because the KeyFile doesn't contain principals, and picks entries by kvno. You'll need to change one of them and then regenerate the KeyFile.Hmm, part of that is a text-replacement error... oops, I was trying to obfuscate my real REALM name, but clearly failed. That line should read "[email protected]" to be consistent with the rest of my output.However, I'm not sure what you mean by "both of those in the KeyFile" - my output of asetkey and bos listkeys shows that I only have one key in the KeyFile:
Right: because if you try to put two keys with the same kvno into a KeyFile, only the last one added will actually be saved. That was what I was trying to tell you; if both of those principals have kvno 2, only one of them will actually be valid. If you use aklog, it will try afs/cell first, but if the key for afs was added after the key for afs/cell, and they both have the same kvno, you will have a token that AFS can't decipher.
However, in my Kerberos ticket cache I do indeed have two tickets with the same kvno.
(1) The restriction I mentioned doesn't apply to ticket caches (or indeed to Kerberos in general); it's specific to the way the AFS KeyFile works.
(2) The only ticket(s) in your ccache that matter are afs/cell or afs. If I read your original message correctly, one ticket was an AFS service ticket and the other was your TGT (expected, and irrelevant for this case).
-- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [email protected] system administrator [openafs,heimdal,too many hats] [email protected] electrical and computer engineering, carnegie mellon university KF8NH
PGP.sig
Description: This is a digitally signed message part
