First, thanks so much for the detailed and fast responses from both of you (Douglas and Brandon). And for being willing to work through some of these details with me. I'll reply to some of your questions, though I suspect that I know what I need to do now...
- The "afs/mycell.edu" service principal was created by creating an >> account >> called "afs" in AD, checking the boxes for "Use DES encryption types for >> this >> account" and "Do not require Kerberos preauthentication", and then running >> "ktpass mapuser afs princ afs/[email protected]" >> > > Was this the full ktpass command? Did you have it create a keytab? > That was the full ktpass command to map the principal "afs/mycell.edu" to a user account "afs". I also ran: ktpass out afs.keytab pass mysecret princ afs/[email protected] kvno 2 to generate a keytab. I specified kvno 2 because in previous tests, the ktpass command always defaulted to using kvno 1 in generated keytabs, even though I could see in my kerberos cache that the kvno was 2. This would cause problems where instead of "bad ticket" errors, I would get "wrong kvno" errors. I have tried this repeatedly, deleting the account in AD, remaking it, and regenerating keytabs with and without specifying kvno. Using this method described above was the only way I have gotten "aklog" to work at all. > And how did you use asetkey with the keytab? > I used WinSCP to transfer the keytab to my afs server, and then ran asetkey add 2 /root/afs.keytab afs/mycell.edu And of course then restarting the service openafs-server. > There is a problem with the W2003 SP1 ktpass. See: > http://support.microsoft.com/kb/919557 > > Have you looked at: > http://www.dementia.org/twiki/bin/view/AFSLore/WindowsK5AfsServicePrincipal I was not aware of these articles. I will delete my existing "afs" account, apply the hotfix in 919557, and follow the steps in the dementia.org site. On Fri, Feb 26, 2010 at 11:12, Brandon S. Allbery KF8NH <[email protected] > wrote: > I'm speculating, but that would be a problem with how Windows implements > the "ktpass mapuser" function and then returns tickets for a mapped user > with the same kvno as the principal. So both the user "afs" and the > principal "afs/mycell.edu" are returning tickets with the same kvno. And > I don't think there are separate entries for these principals in the > kerberos database. > > > Are you saying these are being mapped to the same principal in AD? If so, > it's confusing but should be irrelevant. > Yes, my afs/mycell.edu principal is mapped to a Windows account called "afs" - there was only one account, and a principal mapped to that account. What I tried to say was that if I ran ktpass to generate a keytab for either the afs or afs/mycell.edu principals, I would get the same key back - identical kvno and identical checksum. Otherwise, is there a way for aklog to not bother getting a ticket for the " > [email protected]" principal, and just use > "afs/[email protected]<http://mycell.edu/> > "? > > > That's what it should be doing; only if that principal can't be found or > otherwise fails will it fall back to a...@. > Ok, thanks for that clarification... hopefully, as Douglas suggested, using an account name other than "afs" on windows will cause less confusion, so that aklog only uses the afs/mycell.edu principal. -- Jonathan Nilsson, [email protected] Social Sciences Computing Services 949.824.1536, SSPA 4110, UC Irvine
