[OpenAFS] Active Directory 2003, kerberos 5, openAFS - rxkad
Douglas E. Engert
Wed, 03 Jan 2007 15:36:19 -0600
Jeffrey Altman wrote:
> Compare the keytab files produced with ktutil and ktpass for the same
> key. How are they different?
Does the test AD domain have more then one DC? If so is this a=20
replication timing problem? It may take minutes for all the DCs
to get in sync.
It could be a salt issue, that the newer ktpass might fix. The old=20
ktpass may have made the assumption the salt matched a principal for=20
SamAccountName@DOMAIN which is what I think W2K did. (the SamAccountName=20
is the -mapuser parameter, so would be afs in your case with a salt
I think W2K3 and its ktpass used the standard salt derived from the=20
or in your case
I see in your first note you listed the DES key, and that was what you
added with asetkey. You could also try using the same password
with ktutil and see if it produces the same key which would indicate
if it was using the standard salt. If not try using ktutil with
a principal of afs@LAB.SCANIA.COM which would give the salt that
matches the SamAccountName.
You can see what salt AD is using, by using a network sniffer to look at=20
the KRB5_ERROR message e-data, PA_ENCTYPE_INFO values that lists the=20
salts while doing:
But this does not show what salt ktpass used to create the keytab.
> Jeffrey Altman
> L=F6nroth Erik wrote:
>> OK, I believe have resolved the problem now after 5 whole days of tria=
>> 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: addent -password -p afs/sss.se.scania.com@LAB.SCANIA.COM -k 9 =
>> ktutil: wkt ./keytab.file
>> ktutil: quit
>> This file is then copied to linux and imported exactly as I would norm=
>> asetkey add 9 keytab.file afs/sss.se.scania.com
>> Now - everything works
>> kinit sssler
>> touch /afs/sss.se.scania.com/home/sssler/somefile
>> ls /afs/sss.se.scania.com/home/sssler/somefile
>> I verified this by behaviour - AGAIN - by using the "KTPASS.EXE"
>> (without changing anything else) and importing the key with "asetkey" =
>> C:\ktpass -out afs-keytab-md5-verify -princ
>> afs/sss.se.scania.com@LAB.SCANIA.COM -mapuser afs -crypto DES-CBC-CRC=20
>> -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 proble=
>> 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 ;-)
>> ... and - using this key in AFS - I get the same error again : rxkad
>> I swapped back again to the key generated by ktutil.exe - and it works
>> 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, d=
>> I miss something critical here or is this a bug/feature?
>> -----Original Message-----
>> From: Jeffrey Altman [mailto:firstname.lastname@example.org]
>> Sent: Wed 1/3/2007 3:16 PM
>> To: L=F6nroth Erik
>> Cc: email@example.com
>> Subject: Re: [OpenAFS] Active Directory 2003, kerberos 5, openAFS -
>> rxkad error=3D19270407, arghhhh
>> L=F6nroth Erik wrote:
>>> I believe I have... My file looks like this. Can I be sure this is OK=
>>> In my missery I can't trust anything at the moment.
>>> [root@vmware01 ~]# cat /usr/afs/etc/krb.conf
>>> LAB.SCANIA.COM sesocolab11.scania.com
>> This is fine. Although the second line is not used by AFS so you
>> can remove it.
>> Did you restart the AFS servers after setting this value?
>>> I have also looked in AD to se the Service principal binding (Is this
>>> right?) :
>>> C:\setspn -A afs/sss.se.scania.com afs
>>> Registering ServicePrincipalNames for
>>> Updated object
>>> C:\setspn -L afs
>>> Registered ServicePrincipalNames for
>> That is fine.
>> RXKADBADTICKET can be generated if the clocks between AFS and AD
>> are not synchronized. Are they?
>> Jeffrey Altman
> OpenAFS-info mailing list
Douglas E. Engert <DEEngert@anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439