openldap-technical May 2026

openldap-technical@openldap.org

10 participants
5 discussions

RE27 alpha stages testing call
by Quanah Gibson-Mount 21 May '26

21 May '26

This is an early testing call for the forthcoming OpenLDAP 2.76 series. The initial release state is largely finalized, so suitable for testing configurations, etc. It should not be used in a production environment. Note that the LMDB library has been updated to the 1.0 series, so if deploying this early RE27 into an environment it will be required to do a database dump via slapcat under 2.6, and then import the database with slapadd under 2.7. Generally, get the code for RE27: <https://git.openldap.org/openldap/openldap/-/archive/OPENLDAP_REL_ENG_2_7/o…> Extract, configure, and build. Execute the test suite (via make test) after it is built. Optionally, cd tests && make its to run through the regression suite. Thanks! Regards, Quanah

2 8

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

21 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 21

issue with new cert (now using CN = InCommon RSA OV SSL CA 3)
by steiner＠rutgers.edu 20 May '26

20 May '26

At the moment, I still update LDAP certificates by hand. All previous certs used "C = US, O = Internet2, CN = InCommon RSA Server CA 2" but on May 4th, moved to "C = US, O = "InCommon, LLC", CN = InCommon RSA OV SSL CA 3". I had to generate a new cert after that date... so I added in the new CA certs into my CACert file on both ends. But replication is failing with the new cert, works fine with the old cert: May 13 13:26:21 HOSTNAME slapd[4076661]: slap_client_connect: URI=ldap://master_vip_name/ ldap_sasl_interactive_bind_s failed (-1) May 13 13:26:21 HOSTNAME slapd[4076661]: do_syncrepl: rid=101 rc -1 retrying Tried changing tls_reqcert to never in ldap.conf and in the syncrepl and that didn't change anything. If I move back to the old cert (expires tomorrow) replication works again so probably not a password issue. Any suggestions for debugging this further? thanks, ds

3 12

When exactly do I have to apply the migration steps
by Hans Joachim Multhaupt 06 May '26

06 May '26

Hello the maintenance section of the documentation [1] describes: > the simplest steps needed to migrate between versions or upgrade When exactly do I have to apply these steps? I see these Options: 1. Only when upgrading from e.g. 2.5 to 2.6? 2. Also when upgrading from e.g. 2.6.12 to 2.6.13? 3. Or is this a case-by-case decision (like being necessary when upgrading from 2.6.j to 2.6.j+1 but not for 2.6.k to 2.6.k+1)? The LTS Release Changes [2] mostly contain Bugfixes and some additions and cleanups. So my impression is that the update strategy would only apply to Option 1. Is there any document or official statement, that can be used to confirm/underpin the applying Option? For some context: I have to run openldap with custom schema definitions in a Docker Image (deployed using a Helm Chart) and I have to make sure, that updating to a new Version of that Image will _usually_ not require manual intervention. In addition to the automation aspect there is the time aspect: Creating a Backup is one thing (better being safe than sorry). But importing it again does take quiet a lot of time (about 45 Minutes for an uncompressed 1 GB LDIF file). So I prefer not having to restore a backup _needlessly_. Though these timings might hint to other potential issues, that I did not look into, yet, e.g. attached network storage, indexing, etc. In case of Options 2 and 3 I would have to take an entirely different approach (e.g. creating the Backup with the old Docker Image, while restoring it with the new one), compared to Option 1 (which only happens every-so-often and which _could_ be covered with an explicit and manually executed backup-and-restore procedure). For the time being, replication/scalability is explicitly out-of-scope. References: [1] https://www.openldap.org/doc/admin26/maintenance.html#Migration [2] https://www.openldap.org/software/release/changes_lts.html Kind Regards, Hans Joachim Multhaupt.

2 1

Choice between meta vs ldap+rwm in case of pass-through authentication with SASL against the same LDAP server
by Simon ELBAZ 04 May '26

04 May '26

Hi, I wonder what is the best choice between meta or ldap+rwm backend in case of pass-through authentication with SASL against the same LDAP server. Thanks for any advice -- Simon ELBAZ

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical May 2026