Hi Ondřej
We have been running a brand new openldap on a dedicated fresh server, and has allowed to move away literally anything custom our custom schémas.
Please find below the slapd.conf
# Schema and objectClass definitions include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema
loglevel sync stats moduleload back_mdb
# core DB database mdb suffix "dc=sceur,dc=ch" rootdn "cn=admin,dc=sceur,dc=ch" rootpw "******" directory "/var/lib/ldap"
# user DB database mdb suffix "" rootdn "cn=admin,dc=sceur,dc=ch" directory "/var/lib/ldap/eurospot" timelimit 900 tool-threads 2 idletimeout 60 threads 16
Here is the ldif (oSEclassic.ldif) using the « classic » object
dn: o=Swisscom-Eurospot objectClass: organization o: Swisscom-Eurospot entryDN: o=Swisscom-Eurospot subschemaSubentry: cn=Subschema
We import the ldif this way
service slapd stop find /var/lib/ldap/eurospot -type f -delete slapadd -c -b "o=Swisscom-Eurospot" -l /root/oSEclassic.ldif
And….. ldapsearch -o ldif-wrap=no -LLL -x -b "o=Swisscom-Eurospot" -H ldap://localhost + | sort
createTimestamp: 20260430145139Z creatorsName: cn=admin,dc=sceur,dc=ch dn: o=Swisscom-Eurospot entryCSN: 20260430145139.888833Z#000000#000#000000 entryDN: o=Swisscom-Eurospot entryDN: o=Swisscom-Eurospot entryUUID: d6e971c4-d8ef-1040-9502-8322e1709cea hasSubordinates: FALSE modifiersName: cn=admin,dc=sceur,dc=ch modifyTimestamp: 20260430145139Z structuralObjectClass: organization subschemaSubentry: cn=Subschema subschemaSubentry: cn=Subschema
EntryDN and subschemaSubentry are in double using « out of the box » setup !
Sebastian
Sebastian Perkins Senior Systems Development Engineer 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 http://www.symas.com/http://www.symas.com/ Packaged, certified, and supported LDAP solutions powered by OpenLDAP
