Hide Forgot
Description of problem: With "kerberos method = secrets and keytab" in smb.conf "net ads join" generates /etc/krb5.keytab for host client-123.ad.example.com containing: # klist -ke /etc/krb5.keytab Keytab name: WRFILE:/etc/krb5.keytab KVNO Principal ---- -------------------------------------------------------------------------- 2 host/client-123.ad.example.com.COM (des-cbc-crc) 2 host/client-123.ad.example.com.COM (des-cbc-md5) 2 host/client-123.ad.example.com.COM (arcfour-hmac) 2 host/CLIENT-123.COM (des-cbc-crc) 2 host/CLIENT-123.COM (des-cbc-md5) 2 host/CLIENT-123.COM (arcfour-hmac) 2 CLIENT-123$@AD.EXAMPLE.COM (des-cbc-crc) 2 CLIENT-123$@AD.EXAMPLE.COM (des-cbc-md5) 2 CLIENT-123$@AD.EXAMPLE.COM (arcfour-hmac) However, of these only the third principal can be used (with properly configured krb5.conf, see bug 748407 and bug 748528): # kinit -k -t /etc/krb5.keytab 'host/client-123.ad.example.com.COM' kinit: Client not found in Kerberos database while getting initial credentials # kinit -k -t /etc/krb5.keytab 'host/CLIENT-123.COM' kinit: Client not found in Kerberos database while getting initial credentials # kinit -k -t /etc/krb5.keytab 'CLIENT-123$@AD.EXAMPLE.COM' # klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: CLIENT-123$@AD.EXAMPLE.COM Valid starting Expires Service principal 10/26/11 12:46:43 10/26/11 22:46:29 krbtgt/AD.EXAMPLE.COM.COM renew until 11/02/11 11:46:43 This causes issues with applications expecting the standard host principal (like sshd and mount.cifs, see bug 748402 and bug 748757). If creating a new machine account on AD and generating a keytab for it with: > ktpass /out krb5.keytab /rndpass /crypto all /ptype KRB5_NT_SRV_HST -desonly /princ host/client-123.ad.example.com.COM /mapuser AD\Client-123$ then after transferring the keytab file to client-123.ad.example.com as /etc/krb5.keytab, "kinit -k -t /etc/krb5.keytab 'host/client-123.ad.example.com.COM'" works as expected. Version-Release number of selected component (if applicable): RHEL 6.2
I believe that the "Client not found in Kerberos database" message means that there is no UPN defined in AD by that name. Locate the "client-123" computer object in AD and set its "userPrincipalName" attribute to "host/CLIENT-123.COM". You can go back to your linux box and verify that "kinit -k host/CLIENT-123" works now. Note that I can also confirm that the workaround you mentioned works for me, too.
(In reply to comment #2) > I believe that the "Client not found in Kerberos database" message means that > there is no UPN defined in AD by that name. Correct, indeed a better test is to use kvno: # kvno 'host/client-123.ad.example.com.COM' kvno: Server not found in Kerberos database while getting credentials for host/client-123.ad.example.com.COM # kvno 'host/CLIENT-123.COM' host/CLIENT-123.COM: kvno = 2 # kvno 'CLIENT-123$@AD.EXAMPLE.COM' CLIENT-123$@AD.EXAMPLE.COM: kvno = 2
Since RHEL 6.2 External Beta has begun, and this bug remains unresolved, it has been rejected as it is not proposed as exception or blocker. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux.
This is caused by the issues related to bug 748831 - when the join completes normally all the principals are as expected. Closing this one, further discussion can go to bug 748831. Thanks. *** This bug has been marked as a duplicate of bug 748831 ***