Full_Name: Dirk Kastens Version: 2.4.40 OS: RedHat SL 7.0 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:638:508:3d0:579:e63b:2c0e:3a09) This is a duplicate of #7983 I'm running an openldap server with a meta backend that combines the trees of three different ldap servers. Two of them are connected via starttls and one via ssl over port 636. This perfectly works with openldap-2.4.23. Now I have upgraded the server to RedHat SL 7.0 with openldap-2.4.39. The ssl server cannot be reached by the meta backend any more. I manually compiled openldap 2.4.40, but the effect is the same. I tried openssl and moznss, but this makes no difference. I only see the trees of the tls connected servers. The tls servers also speak ssl, so I simply changed the uri from "ldap:" to "ldaps:". The effect is, that the servers also became unreachable. Here is my configuration: ------------------------------- database meta suffix "ou=new,dc=xyz,dc=de" uri "ldap://ldap.xyz.de/ou=a,ou=new,dc=xyz,dc=de" suffixmassage "ou=a,ou=new,dc=xyz,dc=de" "ou=people,dc=xyz,dc=de" idassert-bind bindmethod=simple binddn="cn=proxy,dc=xyz,dc=de" credentials="secret" mode=self tls_cert=/etc/openldap/certs/client.pem tls_key=/etc/openldap/certs/client.key tls_cacert=/etc/openldap/cacerts/cacerts.pem tls_cacertdir=/etc/openldap/cacerts tls_rcecert=never idassert-authzFrom "dn.exact:cn=root,ou=new,dc=xyz,dc=de" uri "ldaps://ldap.abc.de:636/ou=b,ou=new,dc=xyz,dc=de" suffixmassage "ou=b,ou=new,dc=xyz,dc=de" "ou=people,dc=abc,dc=de" idassert-bind bindmethod=simple binddn="cn=proxy,dc=abc,dc=de" credentials="secret" mode=self starttls=no tls_cert=/etc/openldap/certs/client.pem tls_key=/etc/openldap/certs/client.key tls_cacert=/etc/openldap/cacerts/cacerts.pem tls_cacertdir=/etc/openldap/cacerts tls_reqcert=never idassert-authzFrom "dn.exact:cn=root,ou=new,dc=xyz,dc=de" ------------------------------- When I search the meta directory, I only see the ou=a branch. slapd logs the following: conn=1000 op=1 SRCH base="ou=new,dc=xyz,dc=de" scop3D3D1 deref=3 filter="(objectClass=*)" conn=1000 op=1 SRCH attr=objectclass conn=1000 op=1: meta_back_getconn[0] conn=1000 op=1: meta_back_getconn[1] conn=1000 op=1 meta_back_getconn: candidates=2 conn=ROOTDN-TLS inserted conn=1000 op=1 >E%E> meta_back_search_start[0] conn=1000 op=1 >>> meta_search_dobind_init[0] conn=1000 op=1 <<< meta_search_dobind_init[0]=2 conn=1000 op=1 <<< meta_back_search_start[0]=2 conn=1000 op=1 >>> meta_back_search_start[1] conn=1000 op=1 >>> meta_search_dobind_init[1] conn=1000 op=1 <<< meta_search_dobind_init[1]=4 conn=1000 op=1 <<< meta_back_search_start[1]=4 conn=1000 op=1 meta_back_search: ncandidates=2 cnd="**" conn=1000 op=1 >>> meta_back_search_start[0] conn=1000 op=1 >>> meta_search_dobind_init[5D5D conn=1000 op=1 <<< meta_search_dobind_init[0]=1 ... conn=1000 op=1 <<< meta_back_search_start[0]=1 conn=1000 op=1 >>> meta_search_dobind_init[1] conn=1000 op=1 <<< meta_search_dobind_init[1]=0 ------------------------------- It seems to find both servers, but it only connects to the first one. With ldapsearch I only see the branch "ou=a,ou=new,dc=xyz,dc=de". slapd hangs and can only be terminated by "kill -4". When the first server is specified with ldaps, none of the servers are reachable.
dirk.kastens@uni-osnabrueck.de wrote: > Full_Name: Dirk Kastens > Version: 2.4.40 > OS: RedHat SL 7.0 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2001:638:508:3d0:579:e63b:2c0e:3a09) > > > This is a duplicate of #7983 Then you should have simply followed up to #7983. Does ldapsearch work against the target servers using the certificate configurations you listed? Without a reproducible test case you'll get the same response as #7983 - no evidence of an OpenLDAP software bug, take this to the -technical list for help fixing your configuration. Or take this to RedHat support for help using their build of TLS software. > I'm running an openldap server with a meta backend that combines the > trees of three different ldap servers. Two of them are connected via > starttls and one via ssl over port 636. This perfectly works with > openldap-2.4.23. > Now I have upgraded the server to RedHat SL 7.0 with openldap-2.4.39. > The ssl server cannot be reached by the meta backend any more. I > manually compiled openldap 2.4.40, but the effect is the same. I tried > openssl and moznss, but this makes no difference. I only see the trees > of the tls connected servers. > The tls servers also speak ssl, so I simply changed the uri from "ldap:" > to "ldaps:". The effect is, that the servers also became unreachable. > > Here is my configuration: > ------------------------------- > database meta > suffix "ou=new,dc=xyz,dc=de" > > uri "ldap://ldap.xyz.de/ou=a,ou=new,dc=xyz,dc=de" > suffixmassage "ou=a,ou=new,dc=xyz,dc=de" "ou=people,dc=xyz,dc=de" > idassert-bind bindmethod=simple binddn="cn=proxy,dc=xyz,dc=de" > credentials="secret" mode=self > tls_cert=/etc/openldap/certs/client.pem > tls_key=/etc/openldap/certs/client.key > tls_cacert=/etc/openldap/cacerts/cacerts.pem > tls_cacertdir=/etc/openldap/cacerts > tls_rcecert=never > idassert-authzFrom "dn.exact:cn=root,ou=new,dc=xyz,dc=de" > > uri "ldaps://ldap.abc.de:636/ou=b,ou=new,dc=xyz,dc=de" > suffixmassage "ou=b,ou=new,dc=xyz,dc=de" "ou=people,dc=abc,dc=de" > idassert-bind bindmethod=simple binddn="cn=proxy,dc=abc,dc=de" > credentials="secret" mode=self starttls=no > tls_cert=/etc/openldap/certs/client.pem > tls_key=/etc/openldap/certs/client.key > tls_cacert=/etc/openldap/cacerts/cacerts.pem > tls_cacertdir=/etc/openldap/cacerts > tls_reqcert=never > idassert-authzFrom "dn.exact:cn=root,ou=new,dc=xyz,dc=de" > ------------------------------- > > When I search the meta directory, I only see the ou=a branch. > slapd logs the following: > > conn=1000 op=1 SRCH base="ou=new,dc=xyz,dc=de" scop3D3D1 deref=3 > filter="(objectClass=*)" > conn=1000 op=1 SRCH attr=objectclass > conn=1000 op=1: meta_back_getconn[0] > conn=1000 op=1: meta_back_getconn[1] > conn=1000 op=1 meta_back_getconn: candidates=2 conn=ROOTDN-TLS inserted > conn=1000 op=1 >E%E> meta_back_search_start[0] > conn=1000 op=1 >>> meta_search_dobind_init[0] > conn=1000 op=1 <<< meta_search_dobind_init[0]=2 > conn=1000 op=1 <<< meta_back_search_start[0]=2 > conn=1000 op=1 >>> meta_back_search_start[1] > conn=1000 op=1 >>> meta_search_dobind_init[1] > conn=1000 op=1 <<< meta_search_dobind_init[1]=4 > conn=1000 op=1 <<< meta_back_search_start[1]=4 > conn=1000 op=1 meta_back_search: ncandidates=2 cnd="**" > conn=1000 op=1 >>> meta_back_search_start[0] > conn=1000 op=1 >>> meta_search_dobind_init[5D5D > conn=1000 op=1 <<< meta_search_dobind_init[0]=1 > ... > conn=1000 op=1 <<< meta_back_search_start[0]=1 > conn=1000 op=1 >>> meta_search_dobind_init[1] > conn=1000 op=1 <<< meta_search_dobind_init[1]=0 > ------------------------------- > > It seems to find both servers, but it only connects to the first one. > With ldapsearch I only see the branch "ou=a,ou=new,dc=xyz,dc=de". > slapd hangs and can only be terminated by "kill -4". When the first server is > specified with ldaps, none of the servers are reachable. > > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Hi, > Then you should have simply followed up to #7983. The case has been closed. > Does ldapsearch work against the target servers using the certificate > configurations you listed? Yes. I can directly query the target servers from the redhat server using ldapsearch and ssl.
Dirk Kastens wrote: > Hi, > >> Then you should have simply followed up to #7983. > > The case has been closed. > >> Does ldapsearch work against the target servers using the certificate >> configurations you listed? > Yes. I can directly query the target servers from the redhat server > using ldapsearch and ssl. How about running ldapsearch with -d7, and also the corresponding search against back-meta using slapd -d7. Upload the output somewhere that we can review. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Dirk Kastens wrote: > Hi, > >> How about running ldapsearch with -d7, and also the corresponding search >> against back-meta using slapd -d7. Upload the output somewhere that we >> can review. > > See ftp.openldap.org/incoming/... > > You will find the following files: > > ldapsearch_direct: directly searching the source server with ssl > > ldapsearch_meta_starttls: searching the meta directory where the source > server is connected via starttls (this works) > > ldapsearch_meta_ssl: searching the meta directory where the source > server is connected via ssl (this doesn't work) > > slapd_meta_starttls: meta directory where the source server is connected > via starttls (this works) > > slapd_meta_ssl: meta directory where the source server is connected via > ssl (this doesn't work). slapd hangs after searching and has to be > killed with "kill -4". > > Hope this helps. > I wasn't able to exactly reproduce the problem shown in your logs, but I did find a couple of problems here. For ldaps:// URLs, the back-meta config parser was ignoring the TLS settings. As such, it wasn't able to establish any ldaps session at all, unless there were usable settings in ldap.conf/ldaprc/etc... Also, back-meta was specifying that libldap should open its outbound connections asynchronously, and this wasn't working properly if the async connection succeeded immediately. (I.e., when told to open async, libldap would expect the connection to take a long time to complete, and defer the rest of initialization to a following library call. If it completed immediately, libldap would mis-handle the rest of initialization.) I've pushed fixes for both of these problems to git master and back-meta works on ldaps:// for me now. Since I didn't reproduce your symptoms, I have no idea if this will improve things for you or not. Please test and follow up, thanks. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
changed notes changed state Open to Test moved from Incoming to Software Bugs
Hi, > I've pushed fixes for both of these problems to git master and back-meta > works on ldaps:// for me now. Since I didn't reproduce your symptoms, I > have no idea if this will improve things for you or not. Please test and > follow up, thanks. Great! This perfectly works for me. I just compiled the latest git version. Now the meta directory works with ldaps. Thanks for your support. -- Dirk Kastens Universitaet Osnabrueck, Rechenzentrum (Computer Center) Albrechtstr. 28, 49069 Osnabrueck, Germany Tel.: +49-541-969-2347, FAX: -2470
changed notes changed state Test to Release
fixed in master fixed in RE25 fixed in RE24
changed notes changed state Release to Closed