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,