Hi Ondřej

We have revivied our old ldap setup in prod and test setup 
debian stretch 9.13
slapd is version 2.4.44+dfsg-5+deb9u9
Same configuration

Ldapsearch is fine here, and the slapcat load to the deb9 ldap (in a test environnement) works fine (ie no duplicate extended attributes for entryDN and subschemaSubentry)

It’s using this transfer in the deb 11 setup that we discovered the issue. Also present in deb 13 and the test bed I am running.

I cannot comment for the Debian 10 version, as we migrated from Debian 9 to 11 directly.



Sebastian Perkins
Senior Systems Development Engineer
https://www.linkedin.com/company/planet/
weareplanet.com
De : Ondřej Kuzník <ondra@mistotebe.net>
Date : mercredi, 29 avril 2026 à 17:33
À : Sebastian Perkins <Sebastian.Perkins@hoistgroup.com>
Cc : openldap-technical@openldap.org <openldap-technical@openldap.org>
Objet : Re: Ldapsearch : double on certain extended attributes

CAUTION: This email originated from outside Planet. Do not click links or open attachments unless you recognise the sender and know the content is safe. Please report all suspicious emails by clicking on the report message button in Outlook.

On Wed, Apr 29, 2026 at 08:58:31AM +0000, Sebastian Perkins wrote:
> Hi Ondřej
>
> Sorry for weeks I meant this week…
>
> I have set up a deb 13 test bed with openldap stripped to the bare bones.
>
> [...]
> # Local Schema and objectClass definitions
> include        /etc/ldap/schema/eurospot.schema
> include        /etc/ldap/schema/insight.schema
> [...]
>
> Please note the 2 custom objects « local schema » created by a 3rd
> company a long time ago.
>
> I am running the base tree (not very compliant but fine here)
>
> dn: o=Test-Root
> objectClass: insightOrganization
> o: o=Test-Root
> structuralObjectClass: insightOrganization
> entryUUID: 02df68be-bad7-1037-853d-6b9d76b319d1
> creatorsName: cn=admin,dc=sceur,dc=ch
> createTimestamp: 20180313065342Z
> entryCSN: 20180313065342.301666Z#000000#000#000000
> modifiersName: cn=admin,dc=sceur,dc=ch
> modifyTimestamp: 20180313065342Z
> hasSubordinates: TRUE
> entryDN: o=Test-Root
> subschemaSubentry: cn=Subschema
>
> However the extended attributes provide double entries on the last 2
> properties as described earlier
>
> ldapsearch -o ldif-wrap=no -LLL -x -H ldap://localhost  +
> dn: o=Test-Root
> structuralObjectClass: insightOrganization
> entryUUID: 02df68be-bad7-1037-853d-6b9d76b319d1
> creatorsName: cn=admin,dc=sceur,dc=ch
> createTimestamp: 20180313065342Z
> entryCSN: 20180313065342.301666Z#000000#000#000000
> modifiersName: cn=admin,dc=sceur,dc=ch
> modifyTimestamp: 20180313065342Z
> hasSubordinates: TRUE
>
> entryDN: o=Test-Root
> subschemaSubentry: cn=Subschema
> entryDN: o=Test-Root
> subschemaSubentry: cn=Subschema

Hi Sebastian,
I've just tried the same on a fresh Debian 13 (so 2.6.10+dfsg-1),
swapping out the schemas to a plain `objectClass: organization`, since I
have no idea what's in your schema and you didn't include it. But things
work just fine:

$ ldapsearch -x -H ldapi://socket -o ldif-wrap=no -LLL +
dn: o=Test-Root
structuralObjectClass: organization
entryUUID: 30b25038-d82b-1040-8346-d76423b101c5
creatorsName: cn=admin,dc=sceur,dc=ch
createTimestamp: 20260429152359Z
entryCSN: 20260429152359.666601Z#000000#000#000000
modifiersName: cn=admin,dc=sceur,dc=ch
modifyTimestamp: 20260429152359Z
entryDN: o=Test-Root
subschemaSubentry: cn=Subschema
hasSubordinates: FALSE

So again, there must be something in your setup that's not captured by
the above?

Regards,

--
Ondřej Kuzník
Senior Software Engineer
Symas Corporation                       https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.symas.com%2F&data=05%7C02%7CSebastian.Perkins%40hoistgroup.com%7C2ee3a08d3f034e6fe99b08dea604affd%7Cb607882112c74949982752da66c836c7%7C0%7C0%7C639130736280320661%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=0J8snHYLVqWjwxDR28W4e8Ma2Jw%2Bl8L6hpkVeAdaQuo%3D&reserved=0
Packaged, certified, and supported LDAP solutions powered by OpenLDAP