Hi,

we currently configuring openLDAP with translucent overlay to put in front of some legacy non-openLDAP LDAP servers.

The translucent configuration is as follows:

dn: olcOverlay={3}translucent,olcDatabase={2}mdb,cn=config

objectClass: olcConfig

objectClass: olcOverlayConfig

objectClass: olcTranslucentConfig

objectClass: top

olcOverlay: {3}translucent

olcDisabled: FALSE

olcTranslucentBindLocal: TRUE

dn: olcDatabase={0}ldap,olcOverlay={3}translucent,olcDatabase={2}mdb,cn=config

objectClass: olcConfig

objectClass: olcDatabaseConfig

objectClass: olcLDAPConfig

objectClass: olcTranslucentDatabase

objectClass: top

olcDatabase: {0}ldap

olcDbACLBind: bindmethod=simple binddn=cn=hidden credentials=secret tls_cacert=/etc/ssl/certs/ca-bundle.crt

olcDbStartTLS: ldaps tls_cacert=/etc/ssl/certs/ca-bundle.crt

olcDbURI: ldaps://legacy-ldap-sever/

olcDbUseTemporaryConn: TRUE

Searching via ldapsearch and apache directory studio works fine.

When testing with some other clients we got empty results. Looking into the requests with trace debugLevel we see that some of the clients use different controls in the requests. One of the clients used paging and only got some of the entries back. We could prevent this behavior by filtering the value from the rootDSE by adding the following olcAccess ‘{1}to dn.base="" attrs=supportedControl val/objectIdentifierMatch=1.2.840.113556.1.4.319 by * none’. This “fixed” the problem for this client. Another client seems to use the manageDSAIT (2.16.840.1.113730.3.4.2) control. That seems to receive empty results. We can reproduce the results by adding ‘-E "2.16.840.1.113730.3.4.2"’ to the ldapsearch command. This will also result in an empty result. Unfortunately filtering the control in the same way did not work neither for ldapsearch nor for the other client.

Had someone seen this seeming incompatibility of back_ldap with some or all controls.

Mit freundlichen Grüßen

Clemens (Bergmann)