Hi Chris

Thank you for your fast reply

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=XXXINTRA,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? 

Thank you 

Susan 

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

Reply via email to