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 <qua...@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.bergm...@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
