reporting a problem with LDAP auth to Windows Active Directory with Kerberos using the default spnegoDelegationQop="auth-conf" value for Tomcat 9.0.31 and 9.0.52
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: * We have some web apps that use Tomcat container Kerberos authentication, e.g. we configure the Tomcat Manager app WEB-INF\web.xml with SPNEGO Tomcat Manager Application 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
RE: FW: 403 Errors for REST Web Services after upgrade from 8.5.30 to 8.5.58
Thank you for your response Chris. I am able to segregate a working machine from a non-working machine. I found that debugging and logging can be increased. I will check the logs and let you know if I can find a solution from reading them. -Original Message- From: Christopher Schultz Sent: 14 September 2021 4:02 PM To: users@tomcat.apache.org Subject: Re: FW: 403 Errors for REST Web Services after upgrade from 8.5.30 to 8.5.58 CAUTION: This e-mail originated outside the University of Southampton. Mike, On 9/13/21 10:56, Mike Webb wrote: > I manage a web application that uses REST Web Services. After upgrading from > 8.5.30 to 8.5.58, the web services return 403 messages. > > Commenting out the and sections below > allows the web services to run again, but it does remove the security > constraints. How can I get it working securely again? > > > > admin > readonly > user > > CN=ISSWA-MyWebsiteName-Admin,OU=ISSWA-AppRoles,OU=WebApps,OU=Corporate > Information Services,OU=cp,OU=Services,DC=mywebsitename,DC=com > > CN=ISSWA-MyWebsiteName-Readonly,OU=ISSWA-AppRoles,OU=WebApps,OU=Corporate > Information Services,OU=cp,OU=Services,DC=mywebsitename,DC=com > > CN=ISSWA-MyWebsiteName-User,OU=ISSWA-AppRoles,OU=WebApps,OU > =Corporate Information > Services,OU=cp,OU=Services,DC=mywebsitename,DC=com > > > > CONFIDENTIAL > > > > The server that does not works has > == > Tomcat Version: Apache Tomcat/8.5.58 > JVM Version: 11.0.12+7-LTS > JVM Vendor: Red Hat, Inc. > OS Name: Linux > OS Version: 3.10.0-1160.36.2.el7.x86_64 OS Architecture: amd64 > > > The server that not work has > > Tomcat version: Apache Tomcat/8.5.30 > JVM Version: 11.0.11+9-LTS > JVM Vendor: Red Hat, Inc. > OS Name: Linux > OS Version: 3.10.0-1160.31.1.el7.x86_64 > OS Architecture: amd64 Are you able to segregate that non-working machine to run some tests against it? Can you increase the logging for the authenticator / realm to see what is happening? -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
[ANN] Tomcat 8.5.71 Released
The Apache Tomcat team announces the immediate availability of Apache Tomcat 8.5.71. Apache Tomcat 8 is an open source software implementation of the Java Servlet, JavaServer Pages, Java Unified Expression Language, Java WebSocket and Java Authentication Service Provider Interface for Containers technologies. Apache Tomcat 8.5.71 is a bugfix and feature release. The notable changes compared to 8.5.70 include: - Add a UserDatabase implementation as a superset of the DataSourceRealm functionality. - Update the internal fork of Apache Commons DBCP to 2.9.0, Apache Commons Pool to 2.9.1, Apache Commons FileUpload to 2.0, and Apache Commons Codec to 1.16. - Update the packaged version of the Tomcat Native Library to 1.2.31 to pick up Windows binaries built with OpenSSL 1.1.1l. - Correct parsing of Content-Range headers Along with lots of other bug fixes and improvements. Please refer to the change log for the complete list of changes: http://tomcat.apache.org/tomcat-8.5-doc/changelog.html Downloads: http://tomcat.apache.org/download-80.cgi Migration guides from Apache Tomcat 7.x and 8.0.x: http://tomcat.apache.org/migration.html Enjoy! - The Apache Tomcat team - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: FW: 403 Errors for REST Web Services after upgrade from 8.5.30 to 8.5.58
Mike, On 9/13/21 10:56, Mike Webb wrote: I manage a web application that uses REST Web Services. After upgrading from 8.5.30 to 8.5.58, the web services return 403 messages. Commenting out the and sections below allows the web services to run again, but it does remove the security constraints. How can I get it working securely again? admin readonly user CN=ISSWA-MyWebsiteName-Admin,OU=ISSWA-AppRoles,OU=WebApps,OU=Corporate Information Services,OU=cp,OU=Services,DC=mywebsitename,DC=com CN=ISSWA-MyWebsiteName-Readonly,OU=ISSWA-AppRoles,OU=WebApps,OU=Corporate Information Services,OU=cp,OU=Services,DC=mywebsitename,DC=com CN=ISSWA-MyWebsiteName-User,OU=ISSWA-AppRoles,OU=WebApps,OU=Corporate Information Services,OU=cp,OU=Services,DC=mywebsitename,DC=com CONFIDENTIAL The server that does not works has == Tomcat Version: Apache Tomcat/8.5.58 JVM Version: 11.0.12+7-LTS JVM Vendor: Red Hat, Inc. OS Name: Linux OS Version: 3.10.0-1160.36.2.el7.x86_64 OS Architecture: amd64 The server that not work has Tomcat version: Apache Tomcat/8.5.30 JVM Version: 11.0.11+9-LTS JVM Vendor: Red Hat, Inc. OS Name: Linux OS Version: 3.10.0-1160.31.1.el7.x86_64 OS Architecture: amd64 Are you able to segregate that non-working machine to run some tests against it? Can you increase the logging for the authenticator / realm to see what is happening? -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat8.0.53 & Java related issues
On 14/09/2021 03:59, zhuyix...@orientalmind.com wrote: Dear Sir or Madam: Howdy.I'm a Java developer.I am learning related knowledge of Tomcat.Version for 8.0.53. At present,I have some problems and I hope I can get help. Currently I'm using the org.apache.catalina.util.RequestUtil.parseParameters(). I found this method deprecated after version 8.5.xx.I can't find in the notes or documentation why it was abandoned It was no longer used. and what is the recommended alternative. org.apache.tomcat.util.http.Parameters Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org