[OpenAFS] Re: OpenAFS 1.6.0 with Microsoft Active Directory 2008 -
Questions about DES
Mon, 09 Jan 2012 13:22:19 -0500
I noticed that after I do the ktpass it changes 'User login name' to
afs/pitt.edu even though it was created as afs-pitt-edu-cell. The
'pre-Windows 2000' one does not change. I'm not sure if that is normal
or not. I removed +randpass and set a password. I then tried doing a
kinit manually as you suggested but I get:
[root@afs-dev-03 ~]# kinit afs/pitt.edu@PITT.EDU
kinit: Client not found in Kerberos database while getting initial
Which of course is different than the error aklog gives.
Jeff White - Linux/Unix Systems Engineer
University of Pittsburgh - CSSD
On 01/09/2012 12:20 PM, Douglas E. Engert wrote:
> 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.edu@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
> 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.edu@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:
> addent -password -p afs/pitt.edu@PITT.EDU -kvno 1 -e DES-CBC-MD5
> wkt /tmp/dummy.keytab
> 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.edu@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.edu@PITT.EDU" on that account.
>>> The slash in Kerberos is a name component separator. When aklog
>>> requests a ticket for "afs/pitt.edu@PITT.EDU" it is asking the PITT.EDU
>>> KDC for the principal
>>> "afs" "pitt.edu"
>>> Not the principal
>>> 2. You cannot give the account the name "AFS" or have a short name of
>>> "AFS". Doing so will cause name resolution of "afs@PITT.EDU" to succeed
>>> which will in turn break all of your deployed Windows AFS clients.
>> OpenAFS-info mailing list