Hi Christopher Enclosed is the stacktrace of the tomcat (localhost)
On the DC side we see those messages: Then we see the same error events like we saw before already with the normal log level Internal event: The LDAP server returned an error. Additional Data Error value: 00000057: LdapErr: DSID-0C0C0095, comment: Error decoding ldap message, data 0, v2580 Internal event: An LDAP client connection was closed because of an error. Client IP: 10.189.162.17:51240 Additional Data Error value: 87 The parameter is incorrect. Internal ID: c0c0095 Thank you Susan > -----Original Message----- > From: Christopher Schultz <ch...@christopherschultz.net> > Sent: Donnerstag, 20. Mai 2021 18:37 > To: users@tomcat.apache.org > Subject: Re: JNDI ldaps Problem with SSO > > Susan, > > On 5/18/21 16:58, susan.w...@swisscom.com wrote: > > When we are using plain ldap 3268, all works fine with those settings: > > > > > > Good: > > <Realm className="org.apache.catalina.realm.JNDIRealm" > > connectionURL="ldap://xxxxx.xxxx.com:3268"; > > userBase="DC=XXXINTRA,DC=CH" > > userSubtree="true" > > userSearch="(sAMAccountName={0})" > > userRoleName="memberOf" > > roleBase="OU=PF00_App- > Access,OU=PF00_App,OU=PF00_Server,OU=PF00_Res,OU=PF00,DC=XXXINT > > RA,DC=ch " > > roleName="CN" > > roleSearch="(member:1.2.840.113556.1.4.1941:={0})" > > roleSubtree="true" > > roleNested="true" /> > > > > > > Its when we want to use ldaps with 3269 its failing: > > bad: > > > > <Realm className="org.apache.catalina.realm.JNDIRealm" > > connectionURL="ldaps://xxxxx.xxxx.com:3269" > > userBase="DC=XXXINTRA,DC=CH" > > userSubtree="true" > > userSearch="(sAMAccountName={0})" > > userRoleName="memberOf" > > roleBase="OU=PF00_App- > Access,OU=PF00_App,OU=PF00_Server,OU=PF00_Res,OU=PF00,DC=XXXINT > RA,DC=ch" > > roleName="CN" > > roleSearch="(member:1.2.840.113556.1.4.1941:={0})" > > roleSubtree="true" > > roleNested="true" /> > > > > > > ldapsearch on port 3269 (ldaps) works fine from the same machine, but > > yes, it's not exactly the same request > > > > > > TEST ~]# ldapsearch -x -D > > "cn=SA-PF00-Appway,OU=PF00_Appway- > CoreService,OU=PF00_Appway,OU=PF00_Server,OU=PF00_Res,OU=PF00,dc > =bcintra,dc=ch" -b "DC=bcintra,DC=ch" -W -H ldaps://bcintra.ch:3269 | more > Enter LDAP Password: > > # extended LDIF > > # > > # LDAPv3 > > # base <DC=bcintra,DC=ch> with scope subtree # filter: (objectclass=*) > > # requesting: ALL # Organization, Schema, Configuration, bcintra.ch > > > > > > > > We think, ssl-handshake is fine but bind is failing. Why? > > What is the error you actually get? Can you pleae post the full stack trace > and not just the message? > > -chris > > > >> -----Original Message----- > >> From: Christopher Schultz <ch...@christopherschultz.net> > >> Sent: Dienstag, 18. Mai 2021 18:02 > >> To: users@tomcat.apache.org > >> Subject: Re: JNDI ldaps Problem with SSO > >> > >> Susan, > >> > >> On 5/18/21 09:43, susan.w...@swisscom.com wrote: > >>> Hi all > >>> > >>> apache-tomcat-8.0.36 > >>> > >>> java version "1.8.0_281" > >>> Java(TM) SE Runtime Environment (build 1.8.0_281-b09) Java > >>> HotSpot(TM) 64-Bit Server VM (build 25.281-b09, mixed mode) > >>> > >>> We are having a problem with our Single sign On config. > >>> When using ldap - all works well. > >>> > >>> When switiching to ldaps , the User loses to connection all together > >>> (Server not reachable) > >>> > >>> > >>> > >>> server.xml > >>> > >>> Good: > >>> <Realm className="org.apache.catalina.realm.JNDIRealm" > >>> connectionURL="ldap://xxxxx.xxxx.com:3268"; > >>> userBase="DC=XXXINTRA,DC=CH" > >>> userSubtree="true" > >>> userSearch="(sAMAccountName={0})" > >>> userRoleName="memberOf" > >>> roleBase="OU=PF00_App- > >> > Access,OU=PF00_App,OU=PF00_Server,OU=PF00_Res,OU=PF00,DC=XXXINT > >> RA,DC=ch " > >>> roleName="CN" > >>> roleSearch="(member:1.2.840.113556.1.4.1941:={0})" > >>> roleSubtree="true" > >>> roleNested="true" /> > >>> > >>> bad: > >>> > >>> <Realm className="org.apache.catalina.realm.JNDIRealm" > >>> connectionURL="ldaps://xxxxx.xxxx.com:3269" > >>> userBase="DC=XXXINTRA,DC=CH" > >>> userSubtree="true" > >>> userSearch="(sAMAccountName={0})" > >>> userRoleName="memberOf" > >>> roleBase="OU=PF00_App- > >> > Access,OU=PF00_App,OU=PF00_Server,OU=PF00_Res,OU=PF00,DC=XXXINT > >> RA,DC=ch" > >>> roleName="CN" > >>> roleSearch="(member:1.2.840.113556.1.4.1941:={0})" > >>> roleSubtree="true" > >>> roleNested="true" /> > >>> > >>> > >>> Connectivity to the DC is fine (ldapsearch with ldaps works), SSL > >> connection itself seems to be fine, Certificates are fine, we are > >> sending the trustore as well. All is in the relevant cacerts too. > >>> We have a https Server in Front and a proxy Setting to the tomcat. > >>> > >>> /usr/java/latest/bin/java > >>> -Djava.util.logging.config.file=/opt/tomcat/tomcat8_appway1/conf/log > >>> gi > >>> ng.properties > >>> -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager > >>> -Djavax.net.ssl.trustStore=/etc/pki/tls/certs/xxxxxxxxxxRootCore.jks > >>> -Djavax.net.ssl.trustStorePassword=xxxxxx > >>> -Djdk.tls.ephemeralDHKeySize=2048 -Xmx12G -XX:+UseThreadPriorities > >>> -Dnm.data.home=/opt/tomcat/data > >>> -Djava.security.auth.login.config=/opt/tomcat/data/conf/jaas.conf > >>> - > Djava.security.krb5.conf=/opt/tomcat/tomcat8_appway1/conf/krb5.conf > >>> -Djavax.security.auth.useSubjectCredsOnly=false > >>> -Dsun.security.krb5.debug=false -Duser.timezone=Europe/Berlin > >>> -Djava.endorsed.dirs=/opt/tomcat/apache-tomcat-8.0.36/endorsed > >>> -classpath > >>> /opt/tomcat/apache-tomcat- > >> 8.0.36/bin/bootstrap.jar:/opt/tomcat/apache- > >>> tomcat-8.0.36/bin/tomcat-juli.jar > >>> -Dcatalina.base=/opt/tomcat/tomcat8_appway1 > >>> -Dcatalina.home=/opt/tomcat/apache-tomcat-8.0.36 > >>> -Djava.io.tmpdir=/opt/tomcat/tomcat8_appway1/temp > >>> org.apache.catalina.startup.Bootstrap start > >>> > >>> > >>> > >>> Domain controller seems to close the connection. The Error is "The > >> Parameter is incorrect", "The System cannot find the path specified." > >> Its seems to happen, during the bind process, as if the DC can not > >> decrypt our tomcat request: > >>> > >>> First two events are happening several times. After the last > >>> anonymous > >> bind is entered, the bind exited is done with the appway service account > user. > >> Right after that the error appears. > >>> Internal event: Function ldap_bind entered. > >>> SID: S-1-5-7 > >>> Source IP: 11.1xx.xxx.xxx:51240 > >>> Operation identifier: 894498 > >>> Data1: > >>> Data2: 1004335171 > >>> Data3: > >>> Data4: > >>> Internal event: Function ldap_bind exited. > >>> Elapsed time (ms): 0 > >>> SID: S-1-5-7 > >>> Source IP: 11.1xx.xxx.xxx::51240 > >>> Operation identifier: 894498 > >>> Data1: > >>> Data2: 1004335171 > >>> Data3: 1004335171 > >>> Internal event: Function ldap_bind entered. > >>> SID: S-1-5-7 > >>> Source IP: 11.1xx.xxx.xxx::51240 > >>> Operation identifier: 894498 > >>> Data1: > >>> Data2: 1004335203 > >>> Data3: > >>> Data4: > >>> > >>> Internal event: Function ldap_bind exited. > >>> Elapsed time (ms): 0 > >>> SID: S-1-5-21-576815021-3137181063-3029416097-6939 > >>> Source IP: 11.1xx.xxx.xxx::51240 > >>> Operation identifier: 894498 > >>> Data1: > >>> Data2: 1004335203 > >>> Data3: 1004335203 > >>> > >>> > >>> Then we see the same error events like we saw before already with > >>> the normal log level Internal event: The LDAP server returned an error. > >>> > >>> Additional Data > >>> Error value: > >>> 00000057: LdapErr: DSID-0C0C0095, comment: Error decoding ldap > >>> message, data 0, v2580 > >>> > >>> Internal event: An LDAP client connection was closed because of an > error. > >>> > >>> Client IP: > >>> 11.1xx.xxx.xxx::51240 > >>> > >>> Additional Data > >>> Error value: > >>> 87 The parameter is incorrect. > >>> Internal ID: > >>> c0c0095 > >>> > >>> > >>> > >>> > >>> > >>> > >>> In the App Log of the tomcat we see: > >>> > >>> /opt/tomcat/tomcat8_appway1/logs > >>> > >>> > >>> localhost.2021-03-22.log > >>> > >>> > >>> 22-Mar-2021 10:08:09.717 INFO [localhost-startStop-2] > >> org.apache.catalina.core.ApplicationContext.log > >> [CompressingFilter/1.7.1] CompressingFilter is being destroyed... > >>> 22-Mar-2021 10:08:45.306 INFO [localhost-startStop-1] > >>> org.apache.catalina.core.ApplicationContext.log No Spring > >>> WebApplicationInitializer types detected on classpath > >>> 22-Mar-2021 10:10:02.552 INFO [localhost-startStop-1] > >>> org.apache.catalina.core.ApplicationContext.log > >>> [CompressingFilter/1.7.1] CompressingFilter has initialized > >>> 22-Mar-2021 10:10:02.910 INFO [localhost-startStop-1] > >>> org.apache.catalina.core.ApplicationContext.log jolokia-agent: Using > >>> policy access restrictor classpath:/jolokia-access.xml > >>> 22-Mar-2021 10:10:21.896 SEVERE [http-nio-8080-exec-6] > >>> org.apache.catalina.realm.JNDIRealm.authenticate Exception > >>> performing authentication > >>> javax.naming.NamingException: [LDAP: error code 1 - 000004DC: > LdapErr: > >> DSID-0C0907E9, comment: In order to perform this operation a > >> successful bind must be completed on the connection., data 0, > >> v2580^@]; remaining name 'DC=BCINTRA,DC=CH' > >>> > >>> > >>> 22-Mar-2021 10:16:18.580 SEVERE [http-nio-8080-exec-8] > >>> org.apache.catalina.realm.JNDIRealm.getPrincipal Exception > >>> performing authentication > >>> javax.naming.NamingException: LDAP connection has been closed; > >> remaining name 'DC=BCINTRA,DC=CH' > >>> > >>> > >>> > >>> > >>> What are we missing? > >> > >> Because your AD server sees the connection, it's probably not a TLS > >> handshake failure, but I was wondering if it was a TLS handshake failure. > >> Recent Java versions have e.g. disabled TLSv1 and TLSv1.1, but I > >> think that was done at 1.8 patch 291 and you are on patch 281 > >> > >> Maybe you should be using port 3269 instead of 3268? Looks like 3269 > >> is for TLS and 3268 is for plaintext. > >> > >> > >> You say that ldapsearch works. Can you post that command-line? > >> > >> -chris > >> > B‹KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK > >> KKKKKKKKKCB•È [œÝXœØÜšX™KK[XZ[ > >> > >> ˆ \Ù\œË][œÝXœØÜšX™P ÛXØ] > >> ˜\XÚK›Ü™ÃB‘›ÜˆY][Û˜[ÛÛ[X[™ ËK[XZ[ > >> > >> ˆ \Ù\œËZ[ ÛXØ] > >> ˜\XÚK›Ü™ÃBƒ > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org
--------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
