Hello,
I wanted to report an issue with Tomcat LDAP user authentication lookups with
Tomcat container Kerberos security that I found in our environment when
upgrading to version Tomcat 9.0.52 from 9.0.30 and what configuration settings
bypassed the problem.
Here is our base pre-Tomcat upgrade configuration which was working for both
LDAP user authentication and with Kerberos-enabled authentication (e.g. with
the Tomcat Manager app).
* Tomcat 9.0.30 running on Windows Server 2019
* Microsoft OpenJDK packaging, build 11.0.12+7 64-bit
* Tomcat is authenticating users using LDAP queries to Windows Server
2012R2 Active Directory controllers
* Tomcat server.xml LDAP configuration:
<Realm className="org.apache.catalina.realm.JNDIRealm"
connectionURL="ldaps://dc1.myorg.com:636"
alternateURL="ldaps://dc2.myorg.com:636"
connectionName="dedicated-tomcat-ldap-u...@myorg.com"
connectionPassword="user-secret-password"
userBase="dc=myorg,dc=com"
userSearch="(&(objectClass=user)(sAMAccountName={0}))"
userSubtree="true"
roleBase="dc=myorg,dc=com"
roleSearch="(&(objectClass=group)(member={0}))"
roleSubtree="true"
roleNested="true"
roleName="cn"
adCompat="true"
/>
* We have some web apps that use Tomcat container Kerberos authentication,
e.g. we configure the Tomcat Manager app WEB-INF\web.xml with
<!-- Define the Login Configuration for this Application -->
<login-config>
<!-- Customization: switch Manager app authentication to use SPNEGO
(Kerberos) to get transparent authentication instead of using BASIC auth with a
login popup -->
<auth-method>SPNEGO</auth-method>
<realm-name>Tomcat Manager Application</realm-name>
</login-config>
The same configuration was then upgraded to Tomcat 9.0.52 with otherwise all
the same overall configuration in place (Kerberos settings, Java settings, cert
settings, etc.).
The following problem then appeared when trying to log into the Manager app
using SPNEGO/Kerberos (and also our web apps using Tomcat container Kerberos
authentication).
>From the Tomcat stderr file:
14-Sep-2021 07:00:32.196 SEVERE [https-jsse-nio-443-exec-10]
org.apache.catalina.realm.JNDIRealm.getPrincipal Exception performing
authentication
javax.naming.NamingException: LDAP connection has been closed; remaining name
'dc=myorg,dc=com'
at java.naming/com.sun.jndi.ldap.LdapRequest.getReplyBer(LdapRequest.java:133)
at java.naming/com.sun.jndi.ldap.Connection.readReply(Connection.java:443)
at java.naming/com.sun.jndi.ldap.LdapClient.getSearchReply(LdapClient.java:639)
at java.naming/com.sun.jndi.ldap.LdapClient.search(LdapClient.java:562)
at java.naming/com.sun.jndi.ldap.LdapCtx.doSearch(LdapCtx.java:2014)
at java.naming/com.sun.jndi.ldap.LdapCtx.searchAux(LdapCtx.java:1873)
at java.naming/com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:1798)
at
java.naming/com.sun.jndi.toolkit.ctx.ComponentDirContext.p_search(ComponentDirContext.java:392)
at
java.naming/com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:358)
at
java.naming/com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:341)
at
java.naming/javax.naming.directory.InitialDirContext.search(InitialDirContext.java:267)
at org.apache.catalina.realm.JNDIRealm.getUserBySearch(JNDIRealm.java:1610)
at org.apache.catalina.realm.JNDIRealm.getUser(JNDIRealm.java:1447)
at org.apache.catalina.realm.JNDIRealm.getUser(JNDIRealm.java:1376)
at org.apache.catalina.realm.JNDIRealm.getPrincipal(JNDIRealm.java:2352)
at org.apache.catalina.realm.JNDIRealm.getPrincipal(JNDIRealm.java:2288)
at org.apache.catalina.realm.JNDIRealm.getPrincipal(JNDIRealm.java:2269)
at org.apache.catalina.realm.RealmBase.authenticate(RealmBase.java:504)
at org.apache.catalina.realm.CombinedRealm.authenticate(CombinedRealm.java:365)
at org.apache.catalina.realm.LockOutRealm.authenticate(LockOutRealm.java:194)
...
In testing with Tomcat ver. 9.0.52, I found the following:
* Using Manager with basic auth but still with LDAP user lookups worked -
only Kerberos-enabled apps had problems with LDAP auth
* Switching our connectionURLs to use non-encrypted LDAP instead of LDAPS
caused the problem to be resolved and LDAP+Kerberos to work again so it was
something to do with use of SSL with LDAP (but we only want to use LDAPS, of
course, for security)
* In the LDAP server.xml configuration, as per Tomcat documentation, these
two settings are the defaults if not otherwise specified:
useDelegatedCredential="true"
spnegoDelegationQop="auth-conf "
* As per documentation, these settings cause a users's Kerberos
credentials to be used for the LDAP lookup (if Kerberos credentials are
available to Tomcat) instead of the specific LDAP connection username and
password in the JNDIRealm configuration.
* I tried setting stripRealmForGss="false" (the default is true, where the
domain is stripped from the username) - but has the same problem with both true
and false settings
* I tried adding only the line spnegoDelegationQop="auth" and this caused
the problem to be resolved with Kerberos+LDAP working again
* The options for spnegoDelegationQop are auth-conf (default,
"authentication plus integrity and confidentiality protection"), auth-int
("authentication plus integrity") and auth ("authentication only").
* I also tried auth-int, but this had the same
"org.apache.catalina.realm.JNDIRealm.getPrincipal Exception performing
authentication" error
* I then tested by adding only the line useDelegatedCredential="false" and
this also caused the problem to be resolved with Kerberos+LDAP working again
(presumably by having our Tomcat LDAP user used always for LDAP connection
authentication and not using the end user's Kerberos credential for the LDAP
connection)
As additional information, if relevant, our Windows domain controllers have the
following LDAP connection security setting:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\LdapEnforceChannelBinding
= 1
>From the Microsoft KB article at
>https://support.microsoft.com/en-us/topic/use-the-ldapenforcechannelbinding-registry-entry-to-make-ldap-authentication-over-ssl-tls-more-secure-e9ecfa27-5e57-8519-6ba3-d2c06b21812e
DWORD value: 1 indicates enabled, when supported. All clients that are running
on a version of Windows that has been updated to support channel binding tokens
(CBT) must provide channel binding information to the server. Clients that are
running a version of Windows that has not been updated to support CBT do not
have to do so. This is an intermediate option that allows for application
compatibility.
I also tested previous versions of Tomcat and found the LDAP+Kerberos problem
described started with Tomcat v9.0.31 (and worked with Tomcat v9.0.30).
My conclusion so far is that when using LDAP+Kerberos with Tomcat 9.0.52, the
spnegoDelegationQop values of auth-conf and auth-int don't successfully
authenticate any longer against our Windows domain controllers, but Tomcat
9.0.30 (using the default auth-conf setting as I had not specified this setting
at all) did authenticate successfully. Given that the problem starts with the
auth-int setting, maybe the issue is the Kerberos delegation integrity
connection setting.
Going through the Tomcat changelogs, the bug report could be related as it
describes changes in this code area first released in Tomcat v9.0.31:
https://bz.apache.org/bugzilla/show_bug.cgi?id=64011
This may well be some subtle interaction between Tomcat, the JVM and our Active
Directory servers and may not be a Tomcat problem at all. I wanted to report it
for comment and to let others know who may find the same issue in their own
environments what worked for me so far.
Regards,
Tim Miller Dyck
Tim Miller Dyck (he / him), BMath Hon. (CS), MA - Technical Architect
Kindred Credit Union
Toll Free: 1.888.672.6728, Ext. 5311 | Tel: 519.746.1010
Cell: 519.588.9192 | www.kindredcu.com
Information sent by way of public internet email is non-secure as it is not
encrypted. Kindred Credit Union, Qtrade Asset Management Inc., and Credential
Qtrade Securities Inc. are not responsible if this information is intercepted
and misused. This email and any attachments are confidential, may be covered by
legal professional privilege or exempt from disclosure under applicable law,
and are intended for the addressee only. If you are not the intended recipient,
you are not authorized to and must not disclose, copy, distribute or retain any
or part of this email and any attachment without written permission from
Kindred Credit Union and/or Qtrade Asset Management Inc. and/or Credential
Qtrade Securities Inc. If you have received it in error, please notify the
sender immediately and delete the original. We honour similar requests relating
to the privacy of email communications.
