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