Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am configuring Kerberos authentication for Alfresco CIFS protocol fully implemented in Java (JLAN project). That is not the first time, I used to set it up right in a single shot.

In the same network, with an ActiveDirectory Windows 2008R2 and the same procedure, I have already done successfully the setup for two environments but the production environment give me troubles.

The production keytab was generated by ktpass on ActiveDirectory with RC4-HMAC like for other environments. The account AlfrescoCifsP is dedicated for production and for this only service:

ktpass -princ cifs/
       -mapuser MYDOMAIN\AlfrescoCifsP -pass <password>
       -crypto RC4-HMAC-NT -ptype KRB5_NT_PRINCIPAL -out c:\temp\prod.keytab

Now I try to use it on RedHat 5.8 with MIT Kerberos libraries and utilities in version 1.6.1-70-el4 and I got the following error:

$ kinit -k -t prod.keytab cifs/
kinit(v5): Key table entry not found while getting initial credentials

Here are what I have checked (many times):

  • My krb5.conf is OK with default realm set
  • I can open prod.keytab with ktutil and list the slot for cifs/
  • I can authenticate with password and command kinit cifs/
  • kvno cifs/ returns the same key number than from the keytab entry
  • I also deleted the ActiveDirectory account and does the stuff again. Still the same result.

So everything has been done to succeed. It was successfully for two service accounts and failed for the third one. The only difference may be the SPN length which is a bit longer than for others but far less than the SPN limit of 260 characters.

I have straced the kinit -k -t prod.keytab cifs/... command and I just saw the read operation on keytab file and just behind the output of the error message to stderr.

Is there any known issue matching my trouble in a similar environment ?

How to diagnose the source cause of this issue ?

What may be the main reasons for such a failure ?

What should I try in the hope to find a way out ?

share|improve this question
up vote 2 down vote accepted

Thanks to a network capture, my customer's administrator found a matching issue documented by Novell:

I have added the following lines to my krb5.conf to work-around the issue with kerberos 1.6.1 libraries:

 default_tkt_enctypes = rc4-hmac
 default_tgs_enctypes = rc4-hmac

In my opinion, these lines are not necessary for recent MIT Kerberos libraries.

share|improve this answer
Same problem on Debian 6 with libkrb5-3 in version 1.8.3+dfsg-4squeeze6. Same work-around, I have added enctypes in krb5.conf. – Yves Martin Mar 11 '13 at 13:43

First, you should verify about your computer which running with SPN referenced services, is joined to trust relationship with domain controller (Domain Network in "Open Network and Sharing Center"); once ok, generate ticket again and execute kinit as follow way:

kinit -k -t prod.keytab cifs/

conclusion: you have missing the REALM (@MYDOMAIN.COM)


share|improve this answer
The realm is not missing for the kinit command, as it is correctly declared as the default realm of my Linux system /etc/krb5.conf. – Yves Martin Apr 6 '13 at 13:10
Then there is no need for a Linux system to be "joined to trust relationship" (in Microsoft terms I suppose - and for a Linux, it often means running Samba) to provide Kerberos authentication on various services like HTTP or CIFS. In my case, these two protocols are provided by a Java application in which Kerberos authentication has been implemented. – Yves Martin Apr 6 '13 at 13:13

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.