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)
--On Wednesday, May 14, 2025 10:18 PM +0000 "Bergmann, Clemens" clemens.bergmann@tu-darmstadt.de wrote:
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.
Your clients should not be using the manageDSAIT control, as that specifically says to disable the overlay functionality. So the result is expected. Guessing you can't filter on manageDSAIT for similar reasons.
--Quanah
Hi, thanks for the clarification. After looking into this and understanding the control better I agree that this is to be expected.
We moved away from using translucent for the time being and operate the servers as proxy with back_ldap only. This seems to have fixed the problem with paging.
Kind regards
Clemens
-- Clemens Bergmann Gruppe Nutzermanagement und Entwicklung Technische Universität Darmstadt Hochschulrechenzentrum, Alexanderstraße 2, 64289 Darmstadt Tel. +49 6151 16 71184 http://www.hrz.tu-darmstadt.de/ ________________________________ Von: Quanah Gibson-Mount quanah@fast-mail.org Gesendet: Mittwoch, 18. Juni 2025 22:49 An: Bergmann, Clemens; openldap-technical@openldap.org Betreff: Re: Translucent/back_ldap and controls
--On Wednesday, May 14, 2025 10:18 PM +0000 "Bergmann, Clemens" clemens.bergmann@tu-darmstadt.de wrote:
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.
Your clients should not be using the manageDSAIT control, as that specifically says to disable the overlay functionality. So the result is expected. Guessing you can't filter on manageDSAIT for similar reasons.
--Quanah
On May 14, 2025, at 4:18 PM, Bergmann, Clemens clemens.bergmann@tu-darmstadt.de wrote:
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.
Is the client JNDI?
Unfortunately, its default behavior is to send the manage DSA control on ops.
If this is your situation, it can be overridden by adding this to its runtime when the context is established:
env.put( Context.REFERRAL, "throw" );
— Shawn
openldap-technical@openldap.org
-
Bergmann, Clemens -
Quanah Gibson-Mount -
Shawn McKinney