Hello Susan,

org.apache.catalina.realm.JNDIRealm used the container log so
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].level = ALL
should give you some more details. By default these logs go to
the localhost.YYYY-MM-DD.log, if you want to print them in the console you
can always change the handler
to org.apache.catalina.core.ContainerBase.[Catalina].[localhost].handlers =
java.util.logging.ConsoleHandler

Depending on your Active Directory configuration you may need to provide
connectionName and connectionPassword properties, from [1]:

*"When making a connection in order to search the directory and retrieve
user and role information, the realm authenticates itself to the directory
with the username and password specified by
the connectionName and connectionPassword properties. If these properties
are not specified the connection is anonymous. This is sufficient in many
cases."*

Cheers,

Luis

[1] http://tomcat.apache.org/tomcat-8.0-doc/realm-howto.html









El jue, 25 feb 2021 a las 18:26, Brian Wolfe (<wolfebrian2...@gmail.com>)
escribió:

> 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/
>


-- 

"Ever tried. Ever failed. No matter. Try Again. Fail again. Fail better."

- Samuel Beckett

Reply via email to