openldap-technical June 2026

openldap-technical@openldap.org

8 participants
8 discussions

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

18 Jun '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.

5 4

Building the Admin Guide with sdf on modern perl?
by patrick+openldap.org＠laimbock.com 18 Jun '26

18 Jun '26

Hi, How does the project build the Admin Guide with sdf on modern perl? Fedora 44 has perl-5.42.2 and sdf is no longer compatible with perl-5.30+: sdf -2topics index.sdf $* is no longer supported as of Perl 5.30 at /usr/share/perl5/vendor_perl/sdf/subs.pl line 624. sdf source from https://metacpan.org/release/IANC/sdf-2.001beta1/source Thanks, Patrick

4 3

RE27 alpha stages testing call
by Quanah Gibson-Mount 18 Jun '26

18 Jun '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

5 12

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

18 Jun '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 13

Re: Cannot connect over TLS/SSL (ldaps) on v2.6.9
by Nick Milas 17 Jun '26

17 Jun '26

Hi Emmanuel, Are there any plans for an updated release of Apache Directory Studio? It has been about 6 years without a release and ADS can no more connect to modern LDAP Servers over TLS due to lack of supported ciphers. I would think that an updated release or patch should be considered mandatory. I hope Apache keeps on loving its users :) Best, Nick On 21/5/2025 4:44 μ.μ., Emmanuel Lécharny wrote: > Hi Nick, > > Apache Directory Studio has some issue with TLS 1.3, and we are > working on it. > > On 21/05/2025 11:33, Nick Milas wrote: >> On 21/5/2025 11:52 π.μ., Uwe Sauter wrote: >>> What is the output of your query with "-d -1" added to the command >>> line? What is the output of >>> "openssl s_client -connect $SERVER:636"? >>> >>> Can you query your server when you disable certificate checking in >>> ldap.conf ("TLS_REQCERT allow")? >> >> Hi Uwe, >> >> After further testing, I found that I can connect over ldaps from >> other servers (using ldapsearch) successfully, even from my (Windows) >> workstation with JXplorer, but not from Apache Directory Studio (also >> on my workstation). >> >> Quite strange. ADS can connect to the old server (which has exactly >> the same certificate!) without issues. >> >> I'll (try to) troubleshoot that further, but if you have any ideas, >> they are welcome! >> >> Thanks, >> Nick >> >

2 2

Is the LMDB C library vulnerable to CVE-2019-16244 ?
by alex.seaton＠man.com 04 Jun '26

04 Jun '26

Hi all, This CVE, https://nvd.nist.gov/vuln/detail/CVE-2019-16224 was raised against the py-lmdb library, who patched it here https://github.com/jnwatson/py-lmdb/blob/master/lib/py-lmdb/cve-2019-16224-… (they bundle their own copy of the LMDB C library). It looks like there’s no similar mitigation in the LMDB C library https://github.com/LMDB/lmdb/blob/mdb.master/libraries/liblmdb/mdb.c . Have you looked at this one at all, any idea whether this CVE affects the LMDB library? Thanks, Alex Seaton

2 2

User bind is failing with error LDAP_REFERRAL with ldap_simple_bind API call when LDAP_OPT_REFERRALS=ON in OpenLDAP C SDK 2.6.7
by venugopal chinnakotla 04 Jun '26

04 Jun '26

Hi Team, We are working on migration of nsldap C sdk to OpenLDAP C sdk for our application client code. We are using OpenLDAP 2.6.7. As part of this migration, we are facing one issue related to LDAP Referrals when LDAP_OPT_REFERRALS=ON (which means SDK will handle Referrals internally) While testing our application which makes use of OpenLDAP sdk , we see a difference in the referral handling when LDAP_OPT_REFERRALS=ON when compared with NSLDAP C SDK with user bind We are testing with Oracle Unified Directory, referrals is enabled at server. *With OpenLDAP C SDK:* When our application follows the bind(synchronous) request for the users which is present in another server (where chase should happen) ldap_bind_s → - Which internally calls ldap_sasl_bind_s → ldap_sasl_bind + ldap_result able to succeed the bind (LDAP_SUCCESS). And When our application follows the bind(asynchronous) request for the users which is present in another server (where chase should happen) ldap_simple_bind -> - which internally calls ldap_sasl_bind failed to bind and returned (LDAP_REFERRAL) instead. On further analysis of OpenLDAP code *result.c* (line# 728) we observed, there is exclusion for bind request *tag != LDAP_RES_BIND*, which is preventing to chase the referral internally. * /* Do we need to check for referrals? */ if ( tag != LDAP_RES_BIND && ( LDAP_BOOL_GET(&ld->ld_options, LDAP_BOOL_REFERRALS) || lr->lr_parent != NULL )) { char **refs = NULL; ber_len_t len; /* Check if V3 referral */ if ( ber_peek_tag( &tmpber, &len ) == LDAP_TAG_REFERRAL ) { ... /* Chase the referral */ refer_cnt = ldap_chase_v3referrals( ld, lr, refs, ... );* However, we don't see such exclusion with NSLDAP C SDK specifically for bind requests. We would like to understand the limitation for asynchronous bind when handling referral internally. Are there any known issues/limitations with this use case when OpenLDAP C SDK handles referrals? Is there any way (like any flag/option) to make automatic referrals work with asynchronous bind calls ldap_simple_bind? Please note that, the ldap_search succeeds with when LDAP_OPT_REFERRALS=ON, no issue observed.

2 1

slapo-otp on syncrepl consumer
by Bastian Tweddell 03 Jun '26

03 Jun '26

Hello all, I just began to deploy a testbed with the 2.7 RC, which introduces the compare op for the slapo-otp [1]. TOTP verification works well on a standalone slapd, or a slapd provider DB. 1: https://git.openldap.org/openldap/openldap/-/merge_requests/755 I’m stuck with a configuration issue that I haven’t been able to resolve. In our environment the authentication-clients send TOTP verification requests against a slapd which runs a syncrepl'icated DB; not against the provider. The problem now is that the syncrepl DB is read-only and the slapo-otp overlay wants to update the attributes of the user-entry about the last successful TOTP verification (`attrs=oathTOTPLastTimeStep, oathTOTPTimeStepDrift`). This fails and the error message says 'otp_check_and_update: failed to invalidate provided token rc=53: shadow context; no update referral' I had a go with adding the `updateref` to the syncrepl DB which points back to the provider. The modification of the entry would be sent to the provider and from there distributed to all providers and consumers. Adding `updateref` did not work unfortunately. The error message now says `otp_check_and_update: failed to invalidate provided token rc=10:` I cannot tell where the problem lies. I tried to tune the ACLs on the provider. I opened write access step by step to those entries, ending up with a write access to anonymous. Withour success. I have the suspicion that slapo-otp and the updateref would not work together. I could not figure out if modifications are sent back to the updateref at all. How does updateref with syncrepl is supposed to work? Should the syncrepl-client sending updates to the ref with it's credentials? I would be happy to discuss this issue. I'll paste parts of the configuration of the slapds below. Also the logmessages from the ldapcompare calls Many thanks in advance, slapd provider db config: ``` database mdb suffix dc=fz-juelich,dc=de rootdn cn=admin,dc=fz-juelich,dc=de rootpw ... dbnosync overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 overlay otp index ... multiprovider on ``` slapd consumer db config: ``` database mdb suffix dc=fz-juelich,dc=de rootdn cn=admin,dc=fz-juelich,dc=de rootpw ... dbnosync overlay otp syncrepl rid="1" provider="ldap://test_p0" bindmethod="simple" binddn="cn=consumer,..." keepalive="180:9:75" searchbase="dc=fz-juelich,dc=de" schemachecking="on" type="refreshAndPersist" retry="20 3 60 10 300 +" updateref ldap://test_p0 index ... monitoring on ``` slapd log without `updateref`: ``` conn=1000 fd=14 ACCEPT from IP=... conn=1000 fd=14 TLS established tls_ssf=256 ssf=256 tls_proto=TLSv1.3 tls_cipher=TLS_AES_256_GCM_SHA384 conn=1000 op=0 BIND dn="" method=128 conn=1000 op=0 RESULT tag=97 err=0 qtime=0.000010 etime=0.000055 text= conn=1000 op=1 CMP dn="uid=user,..." attr="oathSecret" conn=1000 op=1 otp_check_and_update: failed to invalidate provided token rc=53: shadow context; no update referral conn=1000 op=1 RESULT tag=111 err=5 qtime=0.000009 etime=0.000310 text= conn=1000 op=2 UNBIND conn=1000 fd=14 closed ``` slapd log with `updateref`: ``` conn=1005 fd=14 ACCEPT from IP=... conn=1005 fd=14 TLS established tls_ssf=256 ssf=256 tls_proto=TLSv1.3 tls_cipher=TLS_AES_256_GCM_SHA384 conn=1005 op=0 BIND dn="" method=128 conn=1005 op=0 RESULT tag=97 err=0 qtime=0.000010 etime=0.000083 text= conn=1005 op=1 CMP dn="uid=user,..." attr="oathSecret" conn=1005 op=1 otp_check_and_update: failed to invalidate provided token rc=10: conn=1005 op=1 RESULT tag=111 err=5 qtime=0.000009 etime=0.000231 text= conn=1005 op=2 UNBIND conn=1005 fd=14 closed ``` -- Bastian Tweddell Juelich Supercomputing Centre phone: +49 (2461) 61-6586 --------------------------------------------------------------------------------------------- --------------------------------------------------------------------------------------------- Forschungszentrum Jülich GmbH 52425 Jülich Sitz der Gesellschaft: Jülich Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Stefan Müller Geschäftsführung: Prof. Dr. Astrid Lambrecht (Vorsitzende), Dr. Stephanie Bauer (stellvertretende Vorsitzende), Prof. Dr. Ir. Pieter Jansens, Prof. Dr. Laurens Kuipers --------------------------------------------------------------------------------------------- ---------------------------------------------------------------------------------------------

2 2

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical June 2026