Shouldn't the " SINGLE-VALUE" definition olcAttributeTypes: ( 1.3.6.1.1.20 NAME 'entryDN' DESC 'DN of the entry' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation ) prevent duplicating the attribute in any case?
Kind regards, Ulrich Windl
-----Original Message----- From: Howard Chu hyc@symas.com Sent: Monday, May 4, 2026 5:35 PM To: Sebastian Perkins Sebastian.Perkins@hoistgroup.com; Erik de Waard erikdewaard@gmail.com Cc: Ondřej Kuzník ondra@mistotebe.net; openldap-technical <openldap- technical@openldap.org> Subject: [EXT] Re: Ldapsearch : double on certain extended attributes
Sicherheits-Hinweis: Diese E-Mail wurde von einer Person außerhalb des UKR gesendet. Seien Sie vorsichtig vor gefälschten Absendern, wenn Sie auf Links klicken, Anhänge öffnen oder weitere Aktionen ausführen, bevor Sie die Echtheit überprüft haben.
Sebastian Perkins wrote:
Hello Erik
Seems you might not have all the history.
Grepping out the 2 extended attributes resolves the import issue. They
actually get created after the ldif import.
So we are trying to pinpoint what part of openldap is causing this
« double » in ldapsearch, but not a slapcat.
Those attributes are dynamically generated by slapd, so they appear in ldapsearch but not in slapcat. But because you included them in your slapadd,they got persisted into the DB and so your subsequent ldapsearches display both the statically persisted attribute and the dynamically generated values.
The slapadd docs state pretty clearly that it's meant to be fed the output of slapcat, not any other LDIF. When you feed it the output of ldapsearch, it's up to you to strip out operational attributes so they don't get persisted erroneously by slapadd.
Sebastian
https://www.weareplanet.com/ Sebastian Perkins Senior Systems Development Engineer
https://www.linkedin.com/company/planet/
weareplanet.com https://www.weareplanet.com/
*De : *Erik de Waard erikdewaard@gmail.com *Date : *lundi, 4 mai 2026 à 13:01 *À : *Sebastian Perkins Sebastian.Perkins@hoistgroup.com *Cc : *Ondřej Kuzník ondra@mistotebe.net; openldap-technical
openldap-technical@openldap.org
*Objet : *Re: Ldapsearch : double on certain extended attributes
You don't often get email from erikdewaard@gmail.com. Learn why this is
important https://aka.ms/LearnAboutSenderIdentification
*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.
Ah ok. You dont mention that in your last mail. So to verify. before
importing oSEclasdic.ldif
You remove the entryDN and subschemaSubentry and then import it?2
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 --
On Mon, May 4, 2026, 10:56 Sebastian Perkins
<Sebastian.Perkins@hoistgroup.com mailto:Sebastian.Perkins@hoistgroup.com> wrote:
Hello Erik That’s what we are currently doing, especially in our ldapsearch basedbackup.
The goal of the thread is to understand what is going on. Sebastian <https://www.weareplanet.com/> Sebastian Perkins Senior Systems Development Engineer https://www.linkedin.com/company/planet/https://www.linkedin.com/company/planet/
weareplanet.com <https://www.weareplanet.com/> <https://utm.io/ujp5N> *De : *Erik de Waard <erikdewaard@gmail.com*Date : *samedi, 2 mai 2026 à 10:19 *À : *Sebastian Perkins <Sebastian.Perkins@hoistgroup.commailto:Sebastian.Perkins@hoistgroup.com>
*Cc : *Ondřej Kuzník <ondra@mistotebe.netmailto:ondra@mistotebe.net>; openldap-technical <openldap- technical@openldap.org
<mailto:openldap-technical@openldap.org>> *Objet : *Re: Ldapsearch : double on certain extended attributes You don't often get email from erikdewaard@gmail.commailto:erikdewaard@gmail.com. Learn why this is important https://aka.ms/LearnAboutSenderIdentification
*CAUTION:* This email originated from outside Planet. Do not click linksor open attachments unless you recognise the sender and know the content is safe.
Please report all suspicious emails by clicking on the report messagebutton in Outlook.
Remove the operational attributes (entryDN subschemaSubentry) fromthe import ldif (oSEclassic.ldif)
On Sat, May 2, 2026, 07:22 Sebastian Perkins<Sebastian.Perkins@hoistgroup.com mailto:Sebastian.Perkins@hoistgroup.com> wrote:
Hi Ondřej We have been running a brand new openldap on a dedicated freshserver, 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" -Hldap://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 <https://www.weareplanet.com/> Sebastian Perkins Senior Systems Development Engineer https://www.linkedin.com/company/planet/https://www.linkedin.com/company/planet/
weareplanet.com <https://www.weareplanet.com/> <https://utm.io/ujp5N> *De : *Ondřej Kuzník <ondra@mistotebe.net*Date : *mercredi, 29 avril 2026 à 17:33 *À : *Sebastian Perkins <Sebastian.Perkins@hoistgroup.commailto:Sebastian.Perkins@hoistgroup.com>
*Cc : *openldap-technical@openldap.org <mailto:openldap-technical@openldap.org> <openldap-technical@openldap.org mailto:openldap-technical@openldap.org>
*Objet : *Re: Ldapsearch : double on certain extended attributes CAUTION: This email originated from outside Planet. Do not click linksor open attachments unless you recognise the sender and know the content is safe.
Please report all suspicious emails by clicking on the report messagebutton 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 barebones.
> > [...] > # 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. Butthings
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 Corporationhttps://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.sy mas.com%2F&data=05%7C02%7CSebastian.Perkins%40hoistgroup.com%7C2 ee3a08d3f034e6fe99b08dea604affd%7Cb607882112c74949982752da66c836c 7%7C0%7C0%7C639130736280320661%7CUnknown%7CTWFpbGZsb3d8eyJF bXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiT WFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=0J8snHYLVqWjwxDR28 W4e8Ma2Jw%2Bl8L6hpkVeAdaQuo%3D&reserved=0
<http://www.symas.com/> Packaged, certified, and supported LDAP solutions powered byOpenLDAP
-- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/