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.
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
>>
>>
>
smime.p7s
Description: S/MIME Cryptographic Signature
