[OpenAFS] Active Directory 2003, kerberos 5, openAFS - rxkad
error=19270407, arghhhh
John W. Sopko Jr.
sopko@cs.unc.edu
Fri, 05 Jan 2007 11:39:03 -0500
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/cs.unc.edu@WIN.CS.UNC.EDU \
> -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?= <erik.lonroth@scania.com>
>>> To: =?iso-8859-1?Q?L=F6nroth_Erik?= <erik.lonroth@scania.com>,
>>> "Jeffrey Altman" <jaltman@secure-endpoints.com>
>>> Cc: <openafs-info@openafs.org>
>>> 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: openafs-info-admin@openafs.org on behalf of L=F6nroth Erik
>>> Sent: Wed 1/3/2007 4:34 PM
>>> To: Jeffrey Altman
>>> Cc: openafs-info@openafs.org
>>> 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/sss.se.scania.com@LAB.SCANIA.COM -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/sss.se.scania.com@LAB.SCANIA.COM -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/sss.se.scania.com@LAB.SCANIA.COM 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