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)