Hi,

I have configured a proxy server with its own local database that is used both to override existing attributes of a remote database and to add its own entries to the directory.

I have configured the local database as subordinate and I have configured a relay database that is also pointing to the local database, but it is using the translucent overlay to connect to the remote ldap directory.

My slapd.conf configuration:

backend hdb backend ldap

database hdb directory /var/lib/ldap suffix "dc=foo,dc=example,dc=com" rootdn "cn=admin,dc=foo,dc=example,dc=com" rootpw secret index objectClass eq subordinate

database relay suffix "dc=example,dc=com" overlay rwm rwm-suffixmassage "dc=foo,dc=example,dc=com" overlay translucent uri ldap://ldap.example.com translucent_bind_local

This configuration actually does exactly what I have been trying to achieve. I can override user attributes and at the same time I can add additional group entries without having root access to the remote server.

I have tested it with the ldap nss service in linux and it works without errors. The updated user accounts are correctly retrieved and the new groups are added transparently. If I use ldapsearch, it will search both the local and the remote server.

The problem that I've experienced is that when I'm using a different ldap client, such as Softerra LDAP Administrator, then the daemon crashes when a search query is performed:

slapd starting conn=1000 fd=11 ACCEPT from IP=X.X.X.X:61230 (IP=0.0.0.0:389) conn=1000 op=0 BIND dn="" method=128 conn=1000 op=0 RESULT tag=97 err=0 text= conn=1000 op=1 SRCH base="dc=example,dc=com" scope=0 deref=0 filter="(objectClass=*)" conn=1000 op=1 SRCH attr=1.1 conn=1000 op=1: back-relay for DN="dc=example,dc=com" would call self. slapd: /build/buildd/openldap-2.4.25/servers/slapd/attr.c:236: attr_dup2: Assertion `j < i' failed. Aborted

The message that "back-relay would call itself" is also logged when using ldapsearch, but ldapsearch does not cause an assertion failure:

slapd starting conn=1000 fd=11 ACCEPT from IP=127.0.0.1:36760 (IP=0.0.0.0:389) conn=1000 op=0 BIND dn="" method=128 conn=1000 op=0 RESULT tag=97 err=0 text= conn=1000 op=1 SRCH base="dc=example,dc=com" scope=2 deref=0 filter="(objectClass=*)" conn=1000 op=1: back-relay for DN="dc=example,dc=com" would call self. PROXIED attributeDescription "ORCLNETDESCSTRING" inserted. conn=1000 op=1 SEARCH RESULT tag=101 err=4 nentries=300 text= conn=1000 op=2 UNBIND conn=1000 fd=11 closed

I'm happy with the proxy functionality that I've managed to configure (which is working), but it's definitely a security vulnerability when simply using a different LDAP client causes the server to crash.

Is there any way I could avoid the assertion failure? Should I post a bug report?

TIA, Mattias