Kerberos Authentication Issue

[Carlos Gunners]

Hello,

I have a situation here where we run an ldap service with round-robin dns
.. so, we advertise a cname that resolves to multiple actual servers.
Also, this cnam is not setup as a service principal in kerberos.

When I try to connect a java app (tomcat8 container, openjdk-7-jre v 7u101,
debian jessie) to this ldap service via GSSAPI/kerberos using a keytab for
auth, it repeatedly fails .. initially failing to find the service
principal in kerberos via its non-canonical hostname (meaning that the java
app totally ignores rdns setting, and thus does no reverse dns check before
trying to obtain a ticket).


When I define a JAVA_OPTION '-Dsun.security.jgss.native=true' to tomcat8,
then the failure changes completely to enctype mismatch type of errors like
below :

> LDAPException(resultCode=82 (local error), errorMessage='An error
occurred while
> attempting to initialize the JAAS login context for GSSAPI
authentication:
> javax.security.auth.login.LoginException: Integrity check on decrypted
field failed (31) -
> PREAUTH_FAILED caused by KrbException: Integrity check on decrypted field
failed (31) -
> PREAUTH_FAILED caused by KrbException: Identifier doesn't match expected
value (906)')

The logs reveal the correct entypes are being used .. ktlog confirms that
the keytab has the correct entypes ..

It's worth noting that we have the same application setup and working
exactly like this with openjdk-6-jre v 6b36 on debian squeeze ..

I have spent so many days trouble-shooting this without success ..

My questions are:
-- how do I force java to respect rdns settings in krb5.conf, and avoid all
these issues ?
-- what's the best practice way to configure for a service designed in this
way?  Or I must define the service principal in kerberos even for a
round-robin presented service?
-- are there any obvious issues I am overlooking ?

Thanks in advance for suggestions, advice ..

best regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20160721/bdd1cb1f/attachment.htm>