I have set up a Kerberos server and OpenLDAP in RHEL5.5. I also have a RHEL6 machine as a client. I have run my Java program using jaas to query the OpenLDAP server from the Linux client.

I can query the OpenLDAP server if I copy the client's keytab to the client machine and use the following configuration options:


I also can query the OpenLDAP server if I am prompted to input the user/password. This leads me to believe that my environment is OK.

However, I'm unable to query the server if I run my Java program after kinit:

[wpingli@pli java]$ klist
Ticket cache: FILE:/tmp/krb5cc_500
Default principal: wpingli@XX.COM
Valid starting Expires Service principal
10/20/11 16:18:06 10/21/11 16:18:02 krbtgt/XX.COM@XX.COM

jaas configuration
com.sun.security.auth.module.Krb5LoginModule required

Debug is true storeKey false useTicketCache true useKeyTab false doNotPrompt true ticketCache is /tmp/krb5cc_500 isInitiator true KeyTab is null refreshKrb5Config is false principal is null tryFirstPass is false useFirstPass is false storePass is false clearPass is false
Acquire TGT from Cache
Principal is null
**null credentials from Ticket Cache
[Krb5LoginModule] authentication failed
Unable to obtain Princpal Name for authentication
Authentication attempt failedjavax.security.auth.login.LoginException: Unable to obtain Princpal Name for authentication**

How can I fix this?

  • Have you tried using this system property: -Djavax.security.auth.useSubjectCredsOnly=false ? Does it work if you specify the principal name explicitly in the configuration (principal="...@REALM.NAME")? – Bruno Oct 21 '11 at 1:35
  • Thanks for your quick reply. I agree with you that I need to using the system property. But it failed with the same error. The principal option does not work as well. – ricky_ru Oct 21 '11 at 2:35
  • If specifying the principal, the error will be "Unable to obtain password from user" – ricky_ru Oct 21 '11 at 2:38
  • You might get more debugging information using these: -Dsun.security.krb5.debug=true -Dsun.security.jgss.debug=true – Bruno Oct 21 '11 at 12:32
  • It reports the encryption type is not supported.(unsupported key type found the default TGT: 18) >>>DEBUG <CCacheInputStream> server principal is krbtgt/XXX.COM@XXX.COM >>>DEBUG <CCacheInputStream> key type: 18 >>>DEBUG <CCacheInputStream> auth time: Mon Oct 24 10:26:30 CST 2011 >>>DEBUG <CCacheInputStream> start time: Mon Oct 24 10:26:30 CST 2011 >>>DEBUG <CCacheInputStream> end time: Tue Oct 25 10:26:30 CST 2011 >>> CCacheInputStream: readFlags() FORWARDABLE; RENEWABLE; INITIAL; >>>DEBUG <CCacheInputStream> >>> unsupported key type found the default TGT: 18 – ricky_ru Oct 24 '11 at 2:51

Java doesn't necessarily support all encryption types supported by (presumably MIT) kinit (libkrb5).

It's possible to configure the encryption types used by libkrb5 in the krb5.conf file (usually in /etc). For example (not necessarily the most secure ones):

# default_tgs_enctypes = aes256-cts arcfour-hmac-md5 des3-hmac-sha1 des-cbc-crc des-cbc-md5
default_tgs_enctypes = des3-hmac-sha1 des-cbc-crc des-cbc-md5

# default_tkt_enctypes = aes256-cts arcfour-hmac-md5 des3-hmac-sha1 des-cbc-crc des-cbc-md5
default_tkt_enctypes = des3-hmac-sha1 des-cbc-crc des-cbc-md5

# permitted_enctypes = aes256-cts arcfour-hmac-md5 des3-hmac-sha1 des-cbc-crc des-cbc-md5
permitted_enctypes = des3-hmac-sha1 des-cbc-crc des-cbc-md5

Which encryption types are supported will depend on the JRE vendor/version and its security providers.

Here is a link to the documentation for Java 6 (Oracle JRE):

|improve this answer|||||
  • Thanks Bruno. Everything works well now. sun jdk and Jrockit have the same security provider while IBM uses its own. – ricky_ru Oct 24 '11 at 3:36
  • Thanks. In my case adding the JCE unlimited strength policy jar files to my java installation did the trick. – Erik Forsberg Apr 30 '15 at 9:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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