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
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
