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
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
ktpass may have made the assumption the salt matched a principal for
[EMAIL PROTECTED] which is what I think W2K did. (the SamAccountName
is the -mapuser parameter, so would be afs in your case with a salt
of "LAB.SCANIA.COMafs".)
I think W2K3 and its ktpass used the standard salt derived from the
principal.
<REALM><component1><component2>...
or in your case
"LAB.SCANIA.COMafssss.se.scania.com"
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 [EMAIL PROTECTED] 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
the KRB5_ERROR message e-data, PA_ENCTYPE_INFO values that lists the
salts while doing:
kinit afs/[EMAIL PROTECTED]
But this does not show what salt ktpass used to create the keytab.
Jeffrey Altman
Lönroth Erik wrote:
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.
On Microsoft AD side:
ktutil
ktutil: addent -password -p afs/[EMAIL PROTECTED] -k 9 -e
des-cbc-crc
ktutil: wkt ./keytab.file
ktutil: quit
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
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 ;-)
... and - using this key in AFS - I get the same error again : rxkad
error=19270407
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
-----Original Message-----
From: Jeffrey Altman [mailto:[EMAIL PROTECTED]
Sent: Wed 1/3/2007 3:16 PM
To: Lönroth Erik
Cc: [email protected]
Subject: Re: [OpenAFS] Active Directory 2003, kerberos 5, openAFS -
rxkad error=19270407, arghhhh
Lönroth 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.
[EMAIL PROTECTED] ~]# cat /usr/afs/etc/krb.conf
LAB.SCANIA.COM
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
CN=afs,OU=Users,OU=VAS,OU=TEST,DC=lab,DC=s
cania,DC=com
afs/sss.se.scania.com
Updated object
C:\setspn -L afs
Registered ServicePrincipalNames for
CN=afs,OU=Users,OU=VAS,OU=TEST,DC=lab,DC=sc
ania,DC=com:
afs/sss.se.scania.com
HOST/afs
HOST/afs.LAB
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
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
--
Douglas E. Engert <[EMAIL PROTECTED]>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
