On 1/9/2012 10:05 AM, Jeff White wrote:
Thanks for the reply. I'm not sure what about short names would cause problems
but I recall hearing about that with AD before so I'll assume it's just a weird
thing/bug with Windows. I originally
created a logon name of 'afs' not 'afs/pitt.edu' so ktpass or something changed
it. I started over with an account named afs-pitt-edu-cell, exported the key,
imported the key, and of course it still
has the DES error as expected. Do you think the KdcUseRequestedEtypesForTickets
registry change which I can't implement without breaking everything as I
mentioned before is why DES is failing? I can
see in gpresult that DES should be allowed and the DES box is checked on the
account so other than that or the attributes Douglas Engert mentioned I don't
know what could be wrong and I'll have to
admit defeat and give up.
C:\Users\jaw171.AFSDC-DEV>ktpass -princ afs/pitt....@pitt.edu -mapuser afs-pitt-
edu-cell -pass * -crypto DES-CBC-MD5 +rndpass /mapop add +desonly /ptype KRB5_NT
_PRINCIPAL +dumpsalt -out afs-pitt-edu-cell.keytab
http://technet.microsoft.com/en-us/library/cc753771(WS.10).aspx
You are specifying both -pass * and +ranpass This looks like it should be
a syntax error and ktpass may be doing something strange.
Did you then enter a password?
If you were to enter a password you could verify that AD has it
correct and that the keytab is correct,
kinit afs/pitt....@pitt.edu
enter password,
should get a ticket verifying that AD has the password.
On unix create a dummy keytab to compare the keytab created by ktpass:
ktutil
addent -password -p afs/pitt....@pitt.edu -kvno 1 -e DES-CBC-MD5
wkt /tmp/dummy.keytab
quit
klist -e -k -t -K /tmp/dummy.keytab
klist -e -k -t -K ktapss.version.keytab
Targeting domain controller: AFSDC-DEV.pitt.edu
Using legacy password setting method
Successfully mapped afs/pitt.edu to afs-pitt-edu-cell.
Building salt with principalname afs/pitt.edu and domain PITT.EDU (encryption ty
pe 3)...
Hashing password with salt "PITT.EDUafspitt.edu".
Key created.
Output keytab to afs-pitt-edu-cell.keytab:
Keytab version: 0x502
keysize 48 afs/pitt....@pitt.edu ptype 1 (KRB5_NT_PRINCIPAL) vno 5 etype 0x3 (DE
S-CBC-MD5) keylength 8 (0x57100bd91a01155d)
Account afs-pitt-edu-cell has been set for DES-only encryption.
Jeff White - Linux/Unix Systems Engineer
University of Pittsburgh - CSSD
On 01/08/2012 11:50 AM, Jeffrey Altman wrote:
Separate from your DES issues, there are two serious problems here.
1. You are creating an account with a logon name of "afs/pitt.edu"
instead of something like "afs-pitt-edu-cell" and then setting a Service
Principal Name of "afs/pitt....@pitt.edu" on that account.
The slash in Kerberos is a name component separator. When aklog
requests a ticket for "afs/pitt....@pitt.edu" it is asking the PITT.EDU
KDC for the principal
"afs" "pitt.edu"
Not the principal
"afs/pitt.edu"
2. You cannot give the account the name "AFS" or have a short name of
"AFS". Doing so will cause name resolution of "a...@pitt.edu" to succeed
which will in turn break all of your deployed Windows AFS clients.
_______________________________________________
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info
--
Douglas E. Engert <deeng...@anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
_______________________________________________
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info
