" I am trying to piece things together like Eric. What we need is clear steps on how to create the Windows AD afs/cell.name user and the proper way to export the afs/cell.name key. Would be nice to have this for both W2K and W2003. The linux "asetkey" man page is real clear on how to do this in linux, (thanks Russ). "
What we do now is that we have replaced the ktpass from WIN2003, SP1 with a working one. We had big problems with a version that generated unusable tickets that gave us the annoying: rxkad error=19270407 We basically follwed the procedure: * Create AFS user in AD and set correct options. "Des only", "Delegate Service", "Password dont expires", "dont change at first login". * Export keytab with "ktpass.exe", just make sure its not the version windows 2003,SP1. * Import it to your AFS:cell(s) with "asetkey". (You might need to restart the openAFS server, I'm not sure.) The thing that made this difficult for us was to find out about the WIN2003,SP1 bugg. /Erik -----Original Message----- From: John W. Sopko Jr. [mailto:[EMAIL PROTECTED] Sent: Fri 1/5/2007 5:39 PM To: [EMAIL PROTECTED] Cc: openafs; Lönroth Erik Subject: Re: [OpenAFS] Active Directory 2003, kerberos 5, openAFS - rxkad error=19270407, arghhhh Jeffrey Altman wrote: > John: > > unless you plan to get rid of the MIT realm and move all of your > principals to active directory, you are going to have to rename > one of the Kerberos realms. I should have been more clear. I am only running a TEST krb5 1.4.4 server under linux. I am still running kaserver. Like lots of folks looking to migrate to K5, have been for years. Our test linux/krb5 server has a different kerberos realm name then the Windows realm name. I am not attempting/planning to run 2 kdc's with the same REALM name. We setup different DNS records to find the kdc's etc. I got k5 authentication working fine. Had problems with the transition kit. I think mostly because the kerberos realm name is different from the afs cell name. (no need to respond to this issue). I would prefer to keep the dns/realm/afs.cell names all the same. The only way to do this is to run one kerberos 5 server. The linux krb5_pam module seems to work fine for authenticating to k5 and getting afs tokens. Aklog works great also. Have tested linux krb5_pam and apache authentication to Windows AD. We run 3 active directory servers, currently Windows 2000 to be upgraded to 2003 very soon. We have a Windows group that manages these machines. I am trying to piece things together like Eric. What we need is clear steps on how to create the Windows AD afs/cell.name user and the proper way to export the afs/cell.name key. Would be nice to have this for both W2K and W2003. The linux "asetkey" man page is real clear on how to do this in linux, (thanks Russ). I plan on trying to attend the AFS & Kerberos Best Practices Workshop 2007. I am sure over the next few months things will get more clear on this. > > In my family there are two first cousins named "Jeffrey" who were > born two weeks apart. Our Mothers both loved the name and refused > to let the other use it, and so, we both got the name and our parents > did not speak to each other for months. We lived blocks away from > each other and went to the same schools and of course once our parents > got over the theft of their child's name, they started to baby sit > for each other. You can imagine what life was like. Any one parent > would call out "Jeffrey" and never know which kid they were going to > get. In the end, there was mutual agreement that when both of the > Jeffreys were present that we would be called by our middle names. > Hence, I became Eric and he became Alan. (This worked just fine > except when our second cousin Alan came to visit but that is a different > story.) > > The point is that your clients and services are always going to be > confused if you have two realms with the same name and no other > mechanism by which they can be identified. Now, because of the desire > to have peer-to-peer realms, there is some discussion about developing > a public key identifier that would turn the realm name into a display > name. However, its not even specified yet let alone a standard and you > wouldn't see it deployed in a Microsoft OS for ten years so there is > little point in considering it. > > Microsoft knows that many Windows 2000 domains were installed using > the same name as MIT Kerberos realms but at the time Windows domains > really did not handle having a name different from the DNS domain. > With the release of Windows 2003, Microsoft fixed the issues with Domain > names vs DNS names and also provided a tool that can be used to rename > the Windows domain. The procedure is painful but it is better than > running two realms with the same name. > > Once the Windows domain has been renamed you can: > > * Create a Windows domain account called "AFS.CS.UNC.EDU" > * Use setspn to assign a service principal name to the account > setspn -A afs/cs.unc.edu AFS.CS.UNC.EDU > * Use a working (non-2003 SP1) version of ktpass to export the key > The 2003 SP1 Support Tools version is 5.2.3790.1830. Do not use it. > The Vista version has not been released yet. It is supposed to be > published under KB926036. I suspect we will see it on Jan 30. > > ktpass -out <keytab> -princ afs/[EMAIL PROTECTED] \ > -crypto DES-CBC-CRC +rndPass -DesOnly > > The vista version of ktpass will allow you to: > -DumpSalt to have it display the salt that was used > -RawSalt <salt> to specify a specific salt > -SetUPN to set the user principal name in addition to the Service > Principal Name > -SetPass to set a user account password > as well as supporting the new AES crypto types. > * copy the keytab to your AFS servers and import the key with asetkey > > The reason that ktutil could be used to generate the keytab was that > the password for the service principal was known. Therefore, ktutil > didn't have to query the Kerberos database. > > Jeffrey Altman > > > > John W. Sopko Jr. wrote: >> I have been following this thread. I also want to test our Windows AD for >> authentication. I have tested a krb5 server on linux and am familiar with >> generating a keytab/KeyFile for the afs/cell.name service principal using >> kadmin and asetkey. I got a bit confused with your Windows AD procedure. >> Could you please summarize and post the steps you used including command >> line options. >> >> For example, one thread says you ran ktutil on linux not Windows but as >> far as I know ktutil on linux is used to manipulate keytabs files not >> export keys from the krb5 principal database. Looks like you basically >> did this: >> >> - Create Windows AD user afs/cell.name user with "DES" key only >> - Used Microsoft 2003 SP1 ktpass.exe to export the afs/cell.name to a >> keytab >> - Used OpenAFS asetkey to import keytab to /usr/afs/etc/KeyFile >> - This did not work >> - You then used ktutil.exe on Windows to to export the afs/cell.name to >> a keytab >> - Used OpenAFS asetkey to import keytab to /usr/afs/etc/KeyFile >> - Success >> - Appears to be some issue with Microsoft 2003 SP1 ktpass.exe >> >> Which ktutil command did you run, on Windows or L/Uinux? >> Where did you get the ktutil command for Windows? >> Did you upgrade to a Microsoft ktpass.exe that worked? >> >> Appreciate the info and the time you saved us! >> >> I would prefer to run the MIT K5 server on linux for OpenAFS but I bet >> others have the same issue I have. Our Windows machines run in the same >> DNS domain as our L/Unix machines. The Windows folks have been running >> AD under our DNS/cell.name/realm name for sometime. Our afs cellname >> is the same as our DNS name. I have tested using a different KRB realm >> name and using the "domain_realm" mapping, it gets confusing to have 2 >> kerberos realm names in the same DNS domain. It does not make sense to >> run 2 different krb5 servers for authentication. >> >> >>> Date: Wed, 3 Jan 2007 16:40:33 +0100 >>> From: =?iso-8859-1?Q?L=F6nroth_Erik?= <[EMAIL PROTECTED]> >>> To: =?iso-8859-1?Q?L=F6nroth_Erik?= <[EMAIL PROTECTED]>, >>> "Jeffrey Altman" <[EMAIL PROTECTED]> >>> Cc: <[email protected]> >>> Subject: RE: [OpenAFS] Active Directory 2003, kerberos 5, openAFS - >>> rxkad error=19270407, arghhhh >>> >>> This is a multi-part message in MIME format. >>> >>> ------_=_NextPart_001_01C72F4D.B4C63582 >>> Content-Type: text/plain; >>> charset="iso-8859-1" >>> Content-Transfer-Encoding: quoted-printable >>> >>> Correction on that: >>> >>> The "ktutil" was run on the linux host! (not windows) >>> >>> But still... the ktpass.exe gives me bogus keyfiles. >>> >>> /Erik >>> >>> >>> -----Original Message----- >>> From: [EMAIL PROTECTED] on behalf of L=F6nroth Erik >>> Sent: Wed 1/3/2007 4:34 PM >>> To: Jeffrey Altman >>> Cc: [email protected] >>> Subject: RE: [OpenAFS] Active Directory 2003, kerberos 5, openAFS - = >>> rxkad error=3D19270407, arghhhh >>> =20 >>> OK, I believe have resolved the problem now after 5 whole days of trial = >>> and error. >>> >>> It turns out that using the "KTPASS" native from Active Directory = >>> generates keys that is not liked by AFS. >>> >>> I instead used ktutil.exe (for windows) to generate my key that I then = >>> imported as usual into AFS. =20 >>> >>> On Microsoft AD side: >>> >>>> ktutil >>> ktutil: addent -password -p afs/[EMAIL PROTECTED] -k 9 >>> -e = >>> des-cbc-crc >>> ktutil: wkt ./keytab.file >>> ktutil: quit=20 >>> >>> This file is then copied to linux and imported exactly as I would = >>> normally: >>> >>> asetkey add 9 keytab.file afs/sss.se.scania.com >>> >>> Now - everything works=20 >>> >>> kinit sssler >>> aklog >>> touch /afs/sss.se.scania.com/home/sssler/somefile >>> ls /afs/sss.se.scania.com/home/sssler/somefile >>> /afs/sss.se.scania.com/home/sssler/somefile >>> >>> Success! >>> >>> I verified this by behaviour - AGAIN - by using the "KTPASS.EXE" = >>> (without changing anything else) and importing the key with "asetkey" >>> as = >>> normal. >>> >>> C:\ktpass -out afs-keytab-md5-verify -princ = >>> afs/[EMAIL PROTECTED] -mapuser afs -crypto DES-CBC-CRC = >>> -pass * >>> Targeting domain controller: SeSoCoLab11.scania.se >>> Successfully mapped afs/sss.se.scania.com to afs. >>> Type the password for afs/sss.se.scania.com: >>> Type the password again to confirm: >>> WARNING: pType and account type do not match. This might cause = >>> problems. >>> Key created. >>> Output keytab to afs-keytab-md5-verify: >>> Keytab version: 0x502 >>> keysize 63 afs/[EMAIL PROTECTED] ptype 0 = >>> (KRB5_NT_UNKNOWN) vno 9 >>> etype 0x1 (DES-CBC-CRC) keylength 8 (0xbff2e56b29943d3e) >>> >>> (Again publishing the key to the whole world ;-)=20 >>> >>> ... and - using this key in AFS - I get the same error again : rxkad = >>> error=3D19270407 >>> >>> I swapped back again to the key generated by ktutil.exe - and it works = >>> again. >>> >>> It seems that using the KTPASS.EXE generates bogus keys for me! >>> >>> I have not read this anywhere and I have read pretty much everyting, >>> did = >>> I miss something critical here or is this a bug/feature? >>> >>> /Erik >>> >>> -- John W. Sopko Jr. University of North Carolina email: sopko AT cs.unc.edu Computer Science Dept., CB 3175 Phone: 919-962-1844 Sitterson Hall; Room 044 Fax: 919-962-1799 Chapel Hill, NC 27599-3175
