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/[email protected]
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/[email protected]
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/[email protected] -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/[email protected]
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/[email protected] -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/[email protected] 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/[email protected]" on that account.
The slash in Kerberos is a name component separator. When aklog
requests a ticket for "afs/[email protected]" 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 "[email protected]" to succeed
which will in turn break all of your deployed Windows AFS clients.
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
