[OpenAFS] Re: OpenAFS 1.6.0 with Microsoft Active Directory 2008 - Questions about DES

[Jeff White]

 From some information Douglas Engert sent off-list...

The attribute msDS-SupportedEncryptionTypes was not set on the account 
but even if I set it to allow DES I still got the same error.  The 
userAccountControl was already set to be DES only.  So that's another 
possible problem proven to not be the issue.

Other possibly useful pieces of information:

sAMAccountName: afs
userPrincipalName: afs/pitt.edu@PITT.EDU
servicePrincipalName: afs/pitt.edu
msDS-SupportedEncryptionTypes: 0

Jeff White - Linux/Unix Systems Engineer
University of Pittsburgh - CSSD


On 01/09/2012 01:22 PM, Jeff White wrote:
> 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
> credentials
>
> 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
>> 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.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:
>>     ktutil
>>
>>      addent -password -p afs/pitt.edu@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.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
>>>>
>>>> "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 "afs@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
>>>
>>>
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info