AW: JNDIRealm with required ChannelBindingToken fails
Hello Michael, > -Ursprüngliche Nachricht- > Von: Michael Osipov > Gesendet: Dienstag, 18. März 2025 22:50 > An: users@tomcat.apache.org > Betreff: Re: JNDIRealm with required ChannelBindingToken fails > > On 2025/03/18 16:22:42 "Thomas Hoffmann (Speed4Trade GmbH)" wrote: > > Hello Tomcat-Team, > > we are currently using a JNDIRealm to authenticate against an > ActiveDirectory via LDAPs. > > For security reasons, the LDAP-Server should be configured to enforce > channel binding token (CBT). > > > > If CBT is set to enforced however, the JNDIRealm fails with this exception: > > > > org.apache.catalina.realm.JNDIRealm.getPrincipal Exception performing > authentication > > javax.naming.AuthenticationException: [LDAP: error code 49 - 80090346: > LdapErr: DSID-0C0906AD, comment: AcceptSecurityContext error, data > 80090346, v4563 ]; remaining name 'ou=xxx,dc=com' > > at > java.naming/com.sun.jndi.ldap.LdapCtx.mapErrorCode(LdapCtx.java:3260 > ) > > ... > > > > Java should support CBT since version 16 according to these pages: > https://bugs.openjdk.org/browse/JDK-8258824 > https://bugs.openjdk.org/browse/JDK-8247311 > > > > It mentions, that a JNDI environment property > "com.sun.jndi.ldap.tls.cbtype" should be set, to make JNDI work with CBT. > > > > Looking at the class JNDIRealm.java --> > getDirectoryContextEnvironment() I can't find any property with this name > or any way to inject additional properties. > > > > The realm configuration in Tomcat is quite common, nothing special: > > > adCompat="true" > > allRolesMode ="authOnly" > > connectionTimeout="3000" > > connectionURL="ldaps://server1:636" > > ... > > useDelegatedCredential="true" > > spnegoDelegationQop="auth" > > /> > > > > Does anybody have succeeded in JNDIReal with CBT? > > Could the connection issue be solved with standard methods? > > There is none and the JNDIRealm does not provide a way to pass arbitrary > properties to the DirContext. you best shot is to extend the class, override > getDirectoryContextEnvironment() and pass the desired property. > > It was actually backported to older versions: > https://bugs.openjdk.org/browse/JDK-8245527 > > My recommendation is to test it in an isolated environment first: > * Plain DirContext > * ldapsearch(1) + Cyrus SASL > > In our huge interprise this isn't enforced, I guess that qop-auth is still > good > enough with aes256-cts-hmac-sha1-96 (SSF 256). Even back then when I > co-reviewed the PR I did not fully understand what the huge benefit of TLS- > CB is if you have AES-256 and auth-conf with Kerberos, but I am not a > security expert. > > Michael > Thank you for your quick reply and confirmation of the current situation. I can test if overriding the getDirectoryContextEnvironment() works. As far as I understood the CBT is created by some connection parameters and prevents MITM attacks via an SSL-Proxy (like Strict-Transport-Security for HTTP does on a higher level). Would it be worth to create a feature request for Tomcat? Companies get more sensitive about security features nowadays and the complexity of the feature doesn’t look very high. Thanks! Thomas
Re: AW: JNDIRealm with required ChannelBindingToken fails
On 2025/03/19 08:02:43 "Thomas Hoffmann (Speed4Trade GmbH)" wrote: > Hello Michael, > > > -Ursprüngliche Nachricht- > > Von: Michael Osipov > > Gesendet: Dienstag, 18. März 2025 22:50 > > An: users@tomcat.apache.org > > Betreff: Re: JNDIRealm with required ChannelBindingToken fails > > > > On 2025/03/18 16:22:42 "Thomas Hoffmann (Speed4Trade GmbH)" wrote: > > > Hello Tomcat-Team, > > > we are currently using a JNDIRealm to authenticate against an > > ActiveDirectory via LDAPs. > > > For security reasons, the LDAP-Server should be configured to enforce > > channel binding token (CBT). > > > > > > If CBT is set to enforced however, the JNDIRealm fails with this > > > exception: > > > > > > org.apache.catalina.realm.JNDIRealm.getPrincipal Exception performing > > authentication > > > javax.naming.AuthenticationException: [LDAP: error code 49 - 80090346: > > LdapErr: DSID-0C0906AD, comment: AcceptSecurityContext error, data > > 80090346, v4563 ]; remaining name 'ou=xxx,dc=com' > > > at > > java.naming/com.sun.jndi.ldap.LdapCtx.mapErrorCode(LdapCtx.java:3260 > > ) > > > ... > > > > > > Java should support CBT since version 16 according to these pages: > > https://bugs.openjdk.org/browse/JDK-8258824 > > https://bugs.openjdk.org/browse/JDK-8247311 > > > > > > It mentions, that a JNDI environment property > > "com.sun.jndi.ldap.tls.cbtype" should be set, to make JNDI work with CBT. > > > > > > Looking at the class JNDIRealm.java --> > > getDirectoryContextEnvironment() I can't find any property with this name > > or any way to inject additional properties. > > > > > > The realm configuration in Tomcat is quite common, nothing special: > > > > > adCompat="true" > > > allRolesMode ="authOnly" > > > connectionTimeout="3000" > > > connectionURL="ldaps://server1:636" > > > ... > > > useDelegatedCredential="true" > > > spnegoDelegationQop="auth" > > > /> > > > > > > Does anybody have succeeded in JNDIReal with CBT? > > > Could the connection issue be solved with standard methods? > > > > There is none and the JNDIRealm does not provide a way to pass arbitrary > > properties to the DirContext. you best shot is to extend the class, override > > getDirectoryContextEnvironment() and pass the desired property. > > > > It was actually backported to older versions: > > https://bugs.openjdk.org/browse/JDK-8245527 > > > > My recommendation is to test it in an isolated environment first: > > * Plain DirContext > > * ldapsearch(1) + Cyrus SASL > > > > In our huge interprise this isn't enforced, I guess that qop-auth is still > > good > > enough with aes256-cts-hmac-sha1-96 (SSF 256). Even back then when I > > co-reviewed the PR I did not fully understand what the huge benefit of TLS- > > CB is if you have AES-256 and auth-conf with Kerberos, but I am not a > > security expert. > > > > Michael > > > > Thank you for your quick reply and confirmation of the current situation. > I can test if overriding the getDirectoryContextEnvironment() works. Pleaso do. > As far as I understood the CBT is created by some connection parameters and > prevents MITM attacks via an SSL-Proxy (like Strict-Transport-Security for > HTTP does on a higher level). Why not just use qop="auth-conf" and avoid TLS altogether? Kerberos will give you all the security you need. I see usecases for the paranoid, but a regular r/o call. > Would it be worth to create a feature request for Tomcat? > Companies get more sensitive about security features nowadays and the > complexity of the feature doesn’t look very high. I'd prefer a generic solution for arbitrary properties like: > additionalProperties="name=value;name2=value2;…" Michael - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: JNDIRealm with required ChannelBindingToken fails
On 2025/03/19 08:02:43 "Thomas Hoffmann (Speed4Trade GmbH)" wrote: > Hello Michael, > > > -Ursprüngliche Nachricht- > > Von: Michael Osipov > > Gesendet: Dienstag, 18. März 2025 22:50 > > An: users@tomcat.apache.org > > Betreff: Re: JNDIRealm with required ChannelBindingToken fails > > > > On 2025/03/18 16:22:42 "Thomas Hoffmann (Speed4Trade GmbH)" wrote: > > > Hello Tomcat-Team, > > > we are currently using a JNDIRealm to authenticate against an > > ActiveDirectory via LDAPs. > > > For security reasons, the LDAP-Server should be configured to enforce > > channel binding token (CBT). > > > > > > If CBT is set to enforced however, the JNDIRealm fails with this > > > exception: > > > > > > org.apache.catalina.realm.JNDIRealm.getPrincipal Exception performing > > authentication > > > javax.naming.AuthenticationException: [LDAP: error code 49 - 80090346: > > LdapErr: DSID-0C0906AD, comment: AcceptSecurityContext error, data > > 80090346, v4563 ]; remaining name 'ou=xxx,dc=com' > > > at > > java.naming/com.sun.jndi.ldap.LdapCtx.mapErrorCode(LdapCtx.java:3260 > > ) > > > ... > > > > > > Java should support CBT since version 16 according to these pages: > > https://bugs.openjdk.org/browse/JDK-8258824 > > https://bugs.openjdk.org/browse/JDK-8247311 > > > > > > It mentions, that a JNDI environment property > > "com.sun.jndi.ldap.tls.cbtype" should be set, to make JNDI work with CBT. > > > > > > Looking at the class JNDIRealm.java --> > > getDirectoryContextEnvironment() I can't find any property with this name > > or any way to inject additional properties. > > > > > > The realm configuration in Tomcat is quite common, nothing special: > > > > > adCompat="true" > > > allRolesMode ="authOnly" > > > connectionTimeout="3000" > > > connectionURL="ldaps://server1:636" > > > ... > > > useDelegatedCredential="true" > > > spnegoDelegationQop="auth" > > > /> > > > > > > Does anybody have succeeded in JNDIReal with CBT? > > > Could the connection issue be solved with standard methods? > > > > There is none and the JNDIRealm does not provide a way to pass arbitrary > > properties to the DirContext. you best shot is to extend the class, override > > getDirectoryContextEnvironment() and pass the desired property. > > > > It was actually backported to older versions: > > https://bugs.openjdk.org/browse/JDK-8245527 > > > > My recommendation is to test it in an isolated environment first: > > * Plain DirContext > > * ldapsearch(1) + Cyrus SASL > > > > In our huge interprise this isn't enforced, I guess that qop-auth is still > > good > > enough with aes256-cts-hmac-sha1-96 (SSF 256). Even back then when I > > co-reviewed the PR I did not fully understand what the huge benefit of TLS- > > CB is if you have AES-256 and auth-conf with Kerberos, but I am not a > > security expert. > > > > Michael > > > > Thank you for your quick reply and confirmation of the current situation. > I can test if overriding the getDirectoryContextEnvironment() works. Pleaso do. > As far as I understood the CBT is created by some connection parameters and > prevents MITM attacks via an SSL-Proxy (like Strict-Transport-Security for > HTTP does on a higher level). Why not just use qop="auth-conf" and avoid TLS altogether? Kerberos will give you all the security you need. I see usecases for the paranoid, but a regular r/o call. > Would it be worth to create a feature request for Tomcat? > Companies get more sensitive about security features nowadays and the > complexity of the feature doesn’t look very high. I'd prefer a generic solution for arbitrary properties like: > additionalProperties="name=value;name2=value2;…" Michael I am just curious... is this a JAVA_OPT at runtime? -Dcom.sun.jndi.ldap.tls.cbtype=enforce what are the enumerated values? -Joey - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat not releasing connector port at shutdown
Hello, I'm using Tomcat 10.1.34 on Debian Bookworm. I have a multiple CATALINA_HOME one CATALINA_BASE configuration, which works perfectly, most of the time. There are 4 CATALINA_HOME setups. The issue is that one of these CATALINA_BASE setups, when getting the shutdown command from the shutdown port, appears to shut down normally. Unfortunately, it never appears to release the connector port for which it's configured. When it's restarted, it fails as it's unable to bind to the port. I've checked using netstat, lsof, ss, ps to see if there's anything else using this port or if the java process for that tomcat instance still exists, with no luck. The process is gone after the shutdown and nothing is using the port, at least that linux can report. I'm wondering if there's an orphaned thread from that instance, perhaps. This instance uses a Spring configuration with log4j2, camel and cxf. I'm not sure what the next troubleshooting step would be here, what to look for. Any guidance on next steps would be appreciated. Thank you, Jason T. Countryman This message and any attachments may contain information that is protected by law as privileged and confidential, and is transmitted for the sole use of the intended recipient(s). If you are not the intended recipient, you are hereby notified that any use, dissemination, copying or retention of this e-mail or the information contained herein is strictly prohibited. If you received this e-mail in error, please immediately notify the sender by e-mail, and permanently delete this e-mail.
RE: [EXTERNAL] Re: Archive localhost_access_log
Thank you again. Thanks and regards, - Quoc A. Nguyen (Contractor) Sr. Software Engineer, Octo an IBM Company Office of Information and Technology (OIT), Development Security, and Operations (DevSecOps) Division: Solution Delivery (SD) Mobile: (407) 404-4912 -Original Message- From: Tim Funk Sent: Tuesday, March 18, 2025 5:26 PM To: Tomcat Users List Subject: Re: [EXTERNAL] Re: Archive localhost_access_log Nothing built in to move them. But the same advice applies. The find command chained with mv or mv+gzip could be a solution Or if your backup policy is good enough. Doing nothing and relying on backups to retrieve old logs would work too. But all of this depends on use case for need of retrieval. Such as how quickly do the files need retrieved. What’s the effort and how often would this happen. On Tue, Mar 18, 2025 at 10:41 AM Nguyen, Quoc A. (QUANTUM MANAGEMENT, LLC) wrote: > Thank you Mr. Funk. > > My request is two-folds a) archive the log files elsewhere (not the "logs" > folder) based on some policy b) clean up (delete) the archived files > based on some policy. > > If I'm not mistaken, your suggestion may address the latter but > nothing on the former? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Verifying tomcat downloads: PGP keys unavailable at https://keys.openpgp.org
Hello, I am trying to verify GPG signatures of recent tomcat downloads, but I noted that both Mark E D Thomas DCFD35E0BF8CA7344752DE8B6FB21E8933C60243 Remy Maucherat 48F8E69F6390C9F25CFEDCD268248959359E722B Are no more available on the https://keys.openpgp.org server I use to look on. Is anyone aware of the reason? Both keys are still present on https://keyserver.ubuntu.com Thanks, rob - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Verifying tomcat downloads: PGP keys unavailable at https://keys.openpgp.org
On 19/03/2025 14:52, Roberto Resoli wrote: Hello, I am trying to verify GPG signatures of recent tomcat downloads, but I noted that both Mark E D Thomas DCFD35E0BF8CA7344752DE8B6FB21E8933C60243 Remy Maucherat 48F8E69F6390C9F25CFEDCD268248959359E722B Are no more available on the https://keys.openpgp.org server I use to look on. Is anyone aware of the reason? Both keys are still present on https://keyserver.ubuntu.com Rob, Let me take a look. As far as I am aware, those keys should never be removed once uploaded. I did receive a request to verify my key from a key server (I forget which) a few weeks ago which I ignored since I hadn't recently uploaded any keys. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Verifying tomcat downloads: PGP keys unavailable at https://keys.openpgp.org
On 19/03/2025 18:51, Mark Thomas wrote: On 19/03/2025 14:52, Roberto Resoli wrote: Hello, I am trying to verify GPG signatures of recent tomcat downloads, but I noted that both Mark E D Thomas DCFD35E0BF8CA7344752DE8B6FB21E8933C60243 Remy Maucherat 48F8E69F6390C9F25CFEDCD268248959359E722B Are no more available on the https://keys.openpgp.org server I use to look on. Is anyone aware of the reason? Both keys are still present on https://keyserver.ubuntu.com Rob, Let me take a look. As far as I am aware, those keys should never be removed once uploaded. I did receive a request to verify my key from a key server (I forget which) a few weeks ago which I ignored since I hadn't recently uploaded any keys. OK. This is a *very* old key that I haven't used to sign releases in years. DCFD 35E0 BF8C A734 4752 DE8B 6FB2 1E89 33C6 0243 My current key is: A9C5 DF4D 22E9 9998 D987 5A51 10C0 1C5A 2F60 59E7 Both the above keys are listed in at least one KEYS file for Tomcat releases. Both the above keys should be signed by multiple ASF committers. The following keys are know to be fake/malicious and should NEVER be trusted: B6DF 153D 456B 3072 959B 7E11 B6FB 7A02 2F60 59E7 B65C A985 6C76 39CD 9D17 7D0E 5385 81D4 33C6 0243 Any other keys associated with ma...@apache.org should be treated as suspicious. I'll let Rémy comment on his keys. Generally, I'd recommend obtaining keys for ASF releases from the associated KEYS file for that release. We watch all commits carefully but any changes to the KEYS files get looked at very closely. I view the key servers as less reliable as there have been fake keys in my name uploaded in the past and I am not convinced it is no longer possible. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
