openldap-technical April 2026

openldap-technical@openldap.org

7 participants
5 discussions

Ldapsearch : double on certain extended attributes
by Sebastian Perkins 07 May '26

07 May '26

Hello All We are running into a very bizarre situation using opendap 2.4.57 on Debian 11 and Debian 13 openldap 2.6.10 When running ldapsearch -LLL -x -H ldap://localhost login=x.y + We get the 2 below extended attributes (and only those) in double entryDN: cn=x.y,ou=Sales,ou=IT,o=Swisscom-Eurospot entryDN: cn=x.y,ou=Sales,ou=IT,o=Swisscom-Eurospot subschemaSubentry: cn=Subschema subschemaSubentry: cn=Subschema Standard attributes are fine A slapcat of the DB is perfect, no double up on the above on any user. phpmyadmin is also OK showing the extended attributes If I slapadd the DB (into the Debian 13 stance) … it works, but I also get the above again This is how we discovered the issue as the dump script used ldapsearch, and we were getting tons of « duplicates » (hence ignored) due to the above. Thanks for any help to resolve this mystery ! Best Sebastian Sebastian Perkins Senior Systems Development Engineer weareplanet.com

5 18

Re: ldap bind response message
by Gustavo Rios 15 Apr '26

15 Apr '26

Thank you for your answer. Em qua., 15 de abr. de 2026 às 11:42, Emmanuel Lecharny <elecharny(a)gmail.com> escreveu: > Hi, > > the first response is a LDAP Message (0x30) of length 12 (0x0C) > [ > https://directory.apache.org/api/internal-design-guide/4.2-asn1-ldap-messag…], > > replying to message #1 (0x02 0x01 0x01), and it's a BindResponse LDAP > Message (0x61) of length 7 (0x07) > [ > https://directory.apache.org/api/internal-design-guide/4.2-asn1-ldap-messag…], > > which LDAPResult result code is 49, ie invalid credentials > [ > https://directory.apache.org/api/internal-design-guide/4.2-asn1-ldap-messag…], > > with no additional matched DN (0x04 0x00) nor diagnostic message (0x04 > 0x00) > > > On 4/14/26 13:52, Gustavo Rios wrote: > > Hi folks! > > > > i am trying to connect to my ldap server and i am having as a response of > > the bind request the following messages: > > > > /* Password: *p = "ypldapA4esupohopdV", > > * result message : 30 c 2 1 1 61 7 a 1 31 4 0 4 0 > > * > > * password : *p = "123456" > > * return : 30 c 2 1 1 61 7 a 1 0 4 0 4 0 > > */ > > > > The first attempt is when the wrong password is given, the second message > > is returned when the correct password is given. > > > > I would like to understand the bytes returned in the bind response; what > > are the last 7 bytes of message response ? > > > > May someone here help me ? > > > > Thanks alot. > > > -- In software systems the price of reliability is the pursuit of the utmost simplicity. It is a price which the very rich find most hard to pay.

1 0

ldap bind response message
by Gustavo Rios 15 Apr '26

15 Apr '26

Hi folks! i am trying to connect to my ldap server and i am having as a response of the bind request the following messages: /* Password: *p = "ypldapA4esupohopdV", * result message : 30 c 2 1 1 61 7 a 1 31 4 0 4 0 * * password : *p = "123456" * return : 30 c 2 1 1 61 7 a 1 0 4 0 4 0 */ The first attempt is when the wrong password is given, the second message is returned when the correct password is given. I would like to understand the bytes returned in the bind response; what are the last 7 bytes of message response ? May someone here help me ? Thanks alot. -- In software systems the price of reliability is the pursuit of the utmost simplicity. It is a price which the very rich find most hard to pay.

3 2

N-Way Multi-Provider with delta-syncrepl: consumer out of sync
by Hawes, David 09 Apr '26

09 Apr '26

While testing n-way multi-provider with delta-syncrepl, I stumbled upon a sequence of events that leaves a consumer out of sync. Assume two providers, provider-1, and provider-2, and a single consumer, consumer-1. They all initially have an attribute with the value 'A'. The following events cause the consumer to be out of sync: 1. Shut down provider-2, and immediately start it again. 2. Within the syncrepl retry window, modify the attribute to value 'B' on provider-2. 3. Within the syncrepl retry window, modify the attribute to value 'B' on provider-1, and then to value 'A' on provider-1. 4. Wait for provider-1 and consumer-1 to retry syncrepl against provider-2. At this point provider-1 and provider-2 will be in sync, but consumer-2 will have the value 'B'. On retry, the modify from provider-2 is written to consumer-1, even though it is older than the modifications it received from provider-1. Before I go too far down the rabbit hole (I've stopped at syncrepl.c:3271 in 2.6.13), I want to ask if n-way multi-provider with delta-syncrepl and a consumer that the providers are unaware of (no syncrepl directives to the consumer) is a valid config. Ideally I'd like to have a consumer with multimaster off to prevent writes completely, and I'd note that config has the same result. Normal syncrepl does not result in an out of sync consumer. So, is this an invalid config, or should I submit an ITS?

3 2

SSL3 alert write:fatal:unknown CA
by Emmanuel Seyman 08 Apr '26

08 Apr '26

Hello, all. I'm using the LTB packages for OpenLDAP 2.5.20 and trying to configure ldaps access. To that end, I have obtained a certificate signed by Allianz Infrastructure CA V, a sub-CA of Allianz Root CA III. https://rootca.allianz.com/en/rootca3.htm I have put: * the certificates of the two CA in /etc/openldap/certs/ldap-ca.crt * the server certificate in /etc/openldap/certs/ldap.crt * the private key in /etc/openldap/certs/ldap.key All files are owned by the 'ldap' user and are readable. Over in slapd.conf, I have configured TLSCACertificateFile, TLSCertificateFile and TLSCertificateKeyFile with the correct filenames and have restarted slapd. An "openssl s_client -connect ..." gives a verify return code of 0 (ok) but an "ldapsearch -x ... -d 1" gives me the following error: TLS trace: SSL_connect:SSLv3/TLS read server hello TLS trace: SSL_connect:TLSv1.3 read encrypted extensions TLS certificate verification: depth: 2, err: 19, subject: /C=DE/O=Allianz/CN=Allianz Root CA III, issuer: /C=DE/O=Allianz/CN=Allianz Root CA III TLS certificate verification: Error, self signed certificate in certificate chain tls_write: want=7, written=7 0000: 15 03 03 00 02 02 30 ...0 TLS trace: SSL3 alert write:fatal:unknown CA TLS trace: SSL_connect:error in error TLS: can't connect: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed (self signed certificate in certificate chain). ldap_err2string ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) Now, it's true that Root CA III is self-signed but that's true of any root CA. Both Infra V and Root III are trusted by the system and show up when I run "trust list --filter=ca-anchors". Am I doing something wrong? Regards, Emmanuel

2 3

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical April 2026