Hi, I had some problems with setting up the keytab with our AD (2008).
Here is some notes from my setup: ---- Active directory does not build the salt the way that AFS normally wants it so we need to build the DES-key in a "special" way. It should be constructed of the account password, domain name in capital letters and the SAM account name as written in the directory. bos_util adddes 3 input key: [password][DOMAIN.NET][SAM-accountname] Retype input key: [password][DOMAIN.NET][SAM-accountname] If the cell name differs from the DOMAIN name we need to configure AFS to know this. echo DOMAIN.NET > /etc/openafs/server/krb.conf ---- In hope that this might help you. Best regards, Emil Assarsson [email protected] Phone: +46 (0)10 8017422 From: [email protected] [mailto:[email protected]] On Behalf Of Jonathan Nilsson Sent: fredag den 26 februari 2010 20:55 To: openafs-info Subject: Re: [OpenAFS] Windows AD Kerberos - "bad ticket" error 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<http://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/mycell.edu<http://mycell.edu>@MYCELL.EDU<http://MYCELL.EDU>" 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<http://mycell.edu>" to a user account "afs". I also ran: ktpass out afs.keytab pass mysecret princ afs/mycell.edu<http://mycell.edu>@MYCELL.EDU<http://MYCELL.EDU> 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<http://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<http://dementia.org> site. On Fri, Feb 26, 2010 at 11:12, Brandon S. Allbery KF8NH <[email protected]<mailto:[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<http://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<http://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<http://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]<mailto:[email protected]>" principal, and just use "afs/mycell.edu<http://mycell.edu/>@MYCELL.EDU<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<http://mycell.edu> principal. -- Jonathan Nilsson, [email protected]<mailto:[email protected]> Social Sciences Computing Services 949.824.1536, SSPA 4110, UC Irvine
