Seems there might be some debug you can turn on. I haven't tried it myself. But Look at this for reference. https://ldapwiki.com/wiki/Tomcat%20And%20LDAP
On Thu, Feb 25, 2021 at 11:18 AM <susan.w...@swisscom.com> wrote: > Dear Brian > > Thank you for your reply > > We can see the successful handshake with the LDAP Server. > We think, after that, some more data goes back and forth and then the > connection is closed. We can't see, what is exactly happening - its TLSv1.3 > When using ldap with port 3268 - its all good. > So the search itself seems to be fine. > > Only ldaps with port 3269 fails > > Is there maybe another debug Option for the ldap? > > Thank you > > Susan > > > > > -----Original Message----- > > From: Brian Wolfe <wolfebrian2...@gmail.com> > > Sent: Donnerstag, 25. Februar 2021 17:00 > > To: Tomcat Users List <users@tomcat.apache.org> > > Subject: Re: JNDI ldaps Problem with SSO > > > > if you define the truststore on the command line it will ignore the > cacerts file. > > Also looks like you're trying to connect to AD over the catalog port. > > I would suggest using the LDAPS port 636. The GC port is used to search > > things within the forest that may not be in the domain. small change but > > shouldn't cause a connection issue if you're using the catalog port. > > > > You shouldn't have to configure any additional SSL stuff on the realm. > As long > > as your JNDI url is ldaps it should know to use SSL. Java will negotiate > the SSL > > for you. > > > > One thing you can do is turn on SSL debug and look at the negotiation to > see > > if it is negotiating SSL. > > *-Djavax.net.debug=ssl* > > You should see it negotiate with the ldap server on startup. You will > also be > > able to see the whole SSL handshake and see if it's failing. > > > > On Thu, Feb 25, 2021 at 10:35 AM <susan.w...@swisscom.com> wrote: > > > > > Hi Bill > > > > > > Thank you for your fast reply > > > > > > We are using RHEL7 > > > > > > The JAVA is using it's default cacerts which includes all ROOT CA's of > > > the LDAP Server. > > > We also added another Trusstore in the JAVA OPTS of the Tomcat JVM, > > > which also includes the whole chain of the LDAP Server Cert: > > > > > > tomcat 21503 1 2 Feb16 ? 05:32:41 > /usr/java/latest/bin/java > > > -Djava.util.logging.config.file=/opt/tomcat/tomcat8_app1/conf/logging. > > > properties > > > -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager > > > -Djavax.net.ssl.trustStore=/etc/pki/tls/certs/RootCore.jks > > > -Djavax.net.ssl.trustStorePassword=xxxxxxx > > > -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_app1/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 > > > > > > Our server.xml only contains the ldap realm and database realm. > > > Could it be, that a ssl config is necessary too? > > > > > > Thank you > > > > > > Susan > > > > > > > -----Original Message----- > > > > From: Bill Stewart <bstew...@iname.com> > > > > Sent: Donnerstag, 25. Februar 2021 16:04 > > > > To: Tomcat Users List <users@tomcat.apache.org> > > > > Subject: Re: JNDI ldaps Problem with SSO > > > > > > > > On Thu, Feb 25, 2021 at 2:31 AM wrote: > > > > > > > > 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=XXXINTRA,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" /> > > > > > > > > > > > > > If you are running Tomcat on Windows, my question is whether the > > > > Java running your Tomcat server trusts the Windows certificate store > > > > for the secure LDAP. > > > > > > > > If you are running Tomcat on Windows, try adding the following > > > > parameter > > > to > > > > the Java command line for your application: > > > > > > > > -Djavax.net.ssl.trustStoreType=WINDOWS-ROOT > > > > > > > > (If you are using procrun which is likely on Windows, this means to > > > > go > > > to the > > > > "Java" tab for the Tomcat service configuration and add the above > > > > line > > > to the > > > > "Java Options" text box.) > > > > > > > > Bill > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > > > > > > -- > > Thanks, > > Brian Wolfe > > https://www.linkedin.com/in/brian-wolfe-3136425a/ > -- Thanks, Brian Wolfe https://www.linkedin.com/in/brian-wolfe-3136425a/
