- openldap-bugs - openldap.org

[Issue 10609] New: slapd SIGABRT/core dump when modifying olcRemoteAuthDNAttribute in cn=config for olcOverlay={0}remoteauth
by openldap-its＠openldap.org 22 Oct '26

22 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=10609 Issue ID: 10609 Summary: slapd SIGABRT/core dump when modifying olcRemoteAuthDNAttribute in cn=config for olcOverlay={0}remoteauth Product: OpenLDAP Version: 2.6.8 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: alain.raimbault(a)thalesgroup.com Target Milestone: --- Vendor Escalation Report — OpenLDAP remoteauth crash & AD bind failures Vendor/Product: OpenLDAP (slapd + remoteauth overlay/module) Module: /usr/lib64/openldap/remoteauth.so.2.0.200 (packaged by openldap-servers) OS: RHEL/CentOS 9 (el9 based; from environment) Symptoms: slapd SIGABRT/core dump when modifying olcRemoteAuthDNAttribute in cn=config for olcOverlay={0}remoteauth AD authentication fails with LDAP bind error Invalid credentials (49) / AD data 52e for multiple username formats 1. Environment Details 1.1 Installed OpenLDAP RPMs markdown content_copy openldap-2.6.8-4.el9.x86_64 openldap-servers-2.6.8-2.el9.x86_64 openldap-clients-2.6.8-4.el9.x86_64 1.2 remoteauth module packaging markdown content_copy rpm -qf /usr/lib64/openldap/remoteauth.so.2.0.200 openldap-servers-2.6.8-2.el9.x86_64 1.3 Module binary location markdown content_copy /usr/lib64/openldap/remoteauth.so -> remoteauth.so.2.0.200 /usr/lib64/openldap/remoteauth.so.2.0.200 1.4 Shared library dependencies (From ldd) libldap.so.2, libsasl2.so.3, libssl.so.3, libcrypto.so.3, libevent-2.1.so.7, etc. 2. Configuration Under Investigation 2.1 Overlay entry (active config) Example retrieved via: markdown content_copy ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// \ -b 'olcOverlay={0}remoteauth,olcDatabase={2}mdb,cn=config' -s base \ '(objectClass=*)' '*' Key attributes observed: olcRemoteAuthDNAttribute: cn olcRemoteAuthDomainAttribute: associatedDomain (as per your dump) olcRemoteAuthMapping: ntdsi ldap://laselainfadc01p.ntdsi.airsystems.thales and mapping to ntdsi.airsystems.thales DC URL olcRemoteAuthTLS: tls_reqcert=never olcRemoteAuthStore: FALSE 2.2 User entry (local LDAP) User searched with: objectClass: domainRelatedObject associatedDomain: ntdsi plus cn and uid values Verified by: markdown content_copy ldapsearch -x -LLL -D 'cn=ldapadmin,...' -W \ -b 'cn=A0007972-R(a)rah-r.thales,ou=Users,...' \ -s base '(objectClass=*)' objectClass associatedDomain Result: objectClass: domainRelatedObject associatedDomain: ntdsi 3. Reproduction of the Crash (Primary Defect) 3.1 How to reproduce slapd is running with remoteauth overlay configured (operational at least prior to this change). Modify the overlay attribute: Change: olcRemoteAuthDNAttribute from cn to uid Example LDIF used: ldif content_copy dn: olcOverlay={0}remoteauth,olcDatabase={2}mdb,cn=config changetype: modify replace: olcRemoteAuthDNAttribute olcRemoteAuthDNAttribute: uid Applied with: bash content_copy ldapmodify -Q -Y EXTERNAL -H ldapi:/// -f change-remoteauth-dnattribute-to-uid.ldif 3.2 Result ldapmodify returns: “Can't contact LDAP server (-1)” slapd.service fails with core-dump / SIGABRT 4. Crash Evidence (Backtrace) From coredumpctl info slapd stack trace (repeated across multiple dumps): Crash location: remoteauth_cf_gen (remoteauth.so.2 + 0x2aee) called from: config_set_vals → config_parse_add → remoteauth_cf_gen Relevant frames: markdown content_copy #5 slap_bv2ad #6 slap_str2ad #7 remoteauth_cf_gen (remoteauth.so.2 + 0x2aee) #8 config_set_vals #9 config_parse_add #10 config_modify_add... Signal: SIGABRT (signal 6) aborted by __assert_fail path 4.3 Service status snippet From systemctl status slapd: “Active: failed (Result: core-dump) … Main PID dumped, signal=ABRT” 5. Additional Observation: AD Bind Failures (Secondary Issue) Multiple direct AD DC bind tests all fail with: ldap_bind: Invalid credentials (49) Additional info: AcceptSecurityContext error, data 52e Tests performed against: ldap://laselainfadc01p.ntdsi.airsystems.thales Tried DN/username forms: A0007972-R(a)rah-r.thales a0007972-r a0007972-r(a)ntdsi.airsystems.thales NTDSI\a0007972-r DN-style bind attempts (e.g., cn=a0007972-r,ou=Users,...) All failed with data 52e. 6. Evidence of remoteauth module being loaded From config dump / module list: cn=module{0},cn=config includes olcModuleLoad: {0}remoteauth module path: /usr/lib64/openldap 7. Expected vs Actual Behavior Expected Changing olcRemoteAuthDNAttribute from cn to uid should: either succeed cleanly, or return a validation/config error to LDAP client slapd should never crash on a config value update. Actual slapd SIGABRTs and produces a core dump during config modify. Crash occurs inside remoteauth_cf_gen() and OpenLDAP attribute string parsing (slap_str2ad, slap_bv2ad). 8. Impact Any attempt to update olcRemoteAuthDNAttribute to uid breaks the LDAP server (core-dump). This prevents applying the likely correct attribute mapping for AD username derivation. In parallel, AD binds return 52e for all tested identifiers/password combinations, which remains unresolved. 9. Suggested Areas for Vendor Investigation Bug/defect in remoteauth overlay when processing olcRemoteAuthDNAttribute value uid especially during config generation (remoteauth_cf_gen) should validate/return error instead of triggering assert() and aborting Potential ABI/config parsing mismatch between: openldap vs openldap-servers builds (mixed releases) Validate correct handling of attribute types / syntax in config parsing: crash path suggests OpenLDAP attribute-name parsing (slap_str2ad / slap_bv2ad) is being fed invalid/unsupported content during overlay config generation 10. Files/Artifacts to Attach (for faster vendor triage) coredumpctl info slapd output(s) stack trace text (as included above) LDIF used for the config modify (the LDIF file contents) slapcat -n 0 section around: olcOverlay={0}remoteauth cn=module{0},cn=config rpm -qi for openldap-servers ldd /usr/lib64/openldap/remoteauth.so.2.0.200 output system logs around the modify attempt: journalctl -u slapd -b -n 200 --no-pager -- You are receiving this mail because: You are on the CC list for the issue.

1 10

[Issue 10596] New: back-ldap: tainting of a cached connection doesn't remove it from cache
by openldap-its＠openldap.org 22 Oct '26

22 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=10596 Issue ID: 10596 Summary: back-ldap: tainting of a cached connection doesn't remove it from cache Product: OpenLDAP Version: 2.6.14 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- The patch for ITS#10550 was incomplete and missed the removal when only tainting. This eventually leaves a freed connection in the tree. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 7649] Feature request: numSubordinates attribute
by openldap-its＠openldap.org 21 Oct '26

21 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=7649 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|2.7.2 |2.7.3 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8375] paged results control results in full db search?
by openldap-its＠openldap.org 21 Oct '26

21 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=8375 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|2.7.2 |2.7.3 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9782] New: regression test its8752 failure
by openldap-its＠openldap.org 21 Oct '26

21 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=9782 Issue ID: 9782 Summary: regression test its8752 failure Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- If a contextCSN update (new cookie) goes from server A through server B to server C, server C will use that CSN to update entryCSN as well (which neither A nor B did). This fails the initial replication check. The issue has likely existed since deltasync was made possible, a version of this is confirmed at least in 2.4.60 onwards to current master. In principle, it is related to concerns raised in ITS#9580. -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Bug 9256] New: The ACLs required for SASL binding are not fully documented
by openldap-its＠openldap.org 21 Oct '26

21 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=9256 Bug ID: 9256 Summary: The ACLs required for SASL binding are not fully documented Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: kop(a)karlpinc.com Target Milestone: --- Created attachment 727 --> https://bugs.openldap.org/attachment.cgi?id=727&action=edit Patch massaging the SASL binding requirement docs While some ACL requirements for SASL binding are documented, some are not. E.g, that olcAuthzRegexp requires =x on objectClass when direct DN mapping is not documented. Other requirements can be reasoned out based on the existing documentation, but this can be very difficult when unfamiliar with all the moving parts and the places they are documented. E.g. knowing that (objectClass=*) is the default filter, and that there's _always_ _some_ filter, and connecting this with ACLs required to do search-based SASL mapping. The attached patch brings all the SASL binding requirements together in one place in the docs and makes everything explicit. The word "SASL" is included, for those searching for that keyword. I, Karl O. Pinc, hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice. -- You are receiving this mail because: You are on the CC list for the bug.

1 30

[Issue 10257] New: Documentation assessment
by openldap-its＠openldap.org 21 Oct '26

21 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=10257 Issue ID: 10257 Summary: Documentation assessment Product: OpenLDAP Version: 2.6.8 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- Created attachment 1031 --> https://bugs.openldap.org/attachment.cgi?id=1031&action=edit Admin guide assessment Last month I commissioned a tech writer to review the current 2.6 Admin Guide to see what needs to be worked on before the 2.7 release. I'm attaching the report here so we can reference it. Should have distributed it sooner but Life got in the way. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10269] New: slap-constraint: Refactor to use a sorted array
by openldap-its＠openldap.org 21 Oct '26

21 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=10269 Issue ID: 10269 Summary: slap-constraint: Refactor to use a sorted array Product: OpenLDAP Version: 2.6.8 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- As noted in the comments for slapo-constraint: /* * Linked list of attribute constraints which we should enforce. * This is probably a sub optimal structure - some form of sorted * array would be better if the number of attributes constrained is * likely to be much bigger than 4 or 5. We stick with a list for * the moment. */ -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10583] New: lloadd logging enhancements
by openldap-its＠openldap.org 21 Oct '26

21 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=10583 Issue ID: 10583 Summary: lloadd logging enhancements Product: OpenLDAP Version: 2.7.0 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: enhancement Priority: --- Component: lloadd Assignee: bugs(a)openldap.org Reporter: smckinney(a)symas.com Target Milestone: --- The logs do not contain the bind result or the identity of the caller which complicates troubleshooting issues. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10086] New: test059 does not set up valid cn=config replication
by openldap-its＠openldap.org 21 Oct '26

21 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=10086 Issue ID: 10086 Summary: test059 does not set up valid cn=config replication Product: OpenLDAP Version: 2.6.4 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: test suite Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- For cn=config replication to be valid, the entryUUIDs must match throughout the config database. However, this is not the case when test059 executes. The entryUUID for 'dn: cn=config' differs between the two. Example: quanah@apito1:~/git/quanah/openldap-scratch/tests/testrun$ grep entryUUID: cfcon.d/cn\=config.ldif entryUUID: aea058c4-bf6e-103d-9e18-4582986e9372 quanah@apito1:~/git/quanah/openldap-scratch/tests/testrun$ grep entryUUID: db.1.a/cn\=config\,cn\=consumer.ldif entryUUID: ae9bd858-bf6e-103d-871e-5daccf782d22 -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10403] New: Add a configuration directive that uses the OpenSSL CONF API to allow openldap config files to set any configuration supported by that API, and to get new OpenSSL configuration capabilities through that API with no changes in openldap.
by openldap-its＠openldap.org 21 Oct '26

21 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=10403 Issue ID: 10403 Summary: Add a configuration directive that uses the OpenSSL CONF API to allow openldap config files to set any configuration supported by that API, and to get new OpenSSL configuration capabilities through that API with no changes in openldap. Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: stephen.wall(a)redcom.com Target Milestone: --- Created attachment 1090 --> https://bugs.openldap.org/attachment.cgi?id=1090&action=edit Add a configuration directive that uses the OpenSSL CONF API to allow openldap config files to set any configuration supported by that API, and to get new OpenSSL configuration capabilities through th I am submitting a patch to create a new directive for OpenLDAP config files that uses the OpenSSL SSL_CONF API to allow configuration of any aspect of OpenSSL that the API supports without adding specific directives to OpenLDAP for them. When OpenSSL extends that API, all versions of OpenLDAP with thie patch will also support those extensions with no additional code. -- You are receiving this mail because: You are on the CC list for the issue.

1 15

[Issue 7335] Create process for updating man pages to handle both cn=config and slapd.conf configurations
by openldap-its＠openldap.org 21 Oct '26

21 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=7335 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|2.7.2 |2.7.3 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10549] New: lloadd rejects proxied connections: proxyp() cannot read PROXY header on non-blocking socket
by openldap-its＠openldap.org 21 Oct '26

21 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=10549 Issue ID: 10549 Summary: lloadd rejects proxied connections: proxyp() cannot read PROXY header on non-blocking socket Product: OpenLDAP Version: 2.6.13 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: lloadd Assignee: bugs(a)openldap.org Reporter: tim.wagner(a)freenet.de Target Milestone: --- # Overview When an lloadd listener is configured with the PROXY protocol enabled, a large fraction of incoming connections are dropped before they are accepted as clients. We're using HAProxy 3.4 (asme with 3.3, 3.2) to distribute the connections across 3 lloadd proxies. The log of lloadd fills with: ``` proxyp(<fd>): header read failed 11 (Resource temporarily unavailable) lload_listener: proxyp(<fd>) failed ``` The root cause is that `proxyp()` is written for a *blocking* socket, but the socket lloadd hands it is *non-blocking*. `proxyp()` (`servers/slapd/proxyp.c`) reads the PROXY header with a single synchronous `tcp_read()` that expects the whole header at once, and its retry loop only handles `EINTR`: ```c /* servers/slapd/proxyp.c:73 */ do { ret = tcp_read( SLAP_FD2SOCK( sfd ), (char *)&pph, sizeof(pph) ); } while ( ret == -1 && errno == EINTR ); if ( ret == -1 ) { ... "header read failed %d (%s)" ... /* EAGAIN lands here */ return 0; } ``` In lloadd, the accept callback runs on a non-blocking fd. The listener is created via libevent without `LEV_OPT_LEAVE_SOCKETS_BLOCKING`: ```c /* servers/lloadd/daemon.c:945 */ listener = evconnlistener_new( listener_base, lload_listener, ls, LEV_OPT_THREADSAFE|LEV_OPT_DEFERRED_ACCEPT, SLAPD_LISTEN_BACKLOG, ls->ls_sd ); ``` libevent's `evconnlistener` sets every accepted socket non-blocking unless that flag is set. `lload_listener()` then calls `proxyp( s, from, &dummy )` (`daemon.c:788`) synchronously, without ever making the fd blocking. So whenever the full PROXY header is not already buffered in the kernel at the moment the accept callback fires, `tcp_read()` returns -1/`EAGAIN`, `proxyp()` returns 0, and lloadd closes the connection. slapd is not affected: it `accept()`s the fd itself and calls `proxyp()` while the fd is still blocking (only the *listening* socket is made non-blocking, `servers/slapd/daemon.c:2624`; Linux `accept()` does not inherit `O_NONBLOCK`), so the single-shot reads block until the header arrives. # Actual Results Many connections are refused with (we see 7-12/s on every ldap proxy): ``` proxyp(<fd>): header read failed 11 (Resource temporarily unavailable) lload_listener: proxyp(<fd>) failed ``` The PROXY header is never parsed; the connection is closed. # Expected Results `proxyp()` should wait for the PROXY header to arrive (up to a timeout) on a non-blocking socket, parse it, and let the connection proceed — matching the behavior lloadd users get from slapd. # Additional Information (my speculation and assumptions) 1. **Primary trigger.** The specific errno-11 message requires an open, non-blocking fd with *zero* bytes buffered. A peer that completes the TCP handshake but has not yet sent the header produces exactly this. `TCP_DEFER_ACCEPT` (from `LEV_OPT_DEFERRED_ACCEPT`) reduces the race but does not remove it: its retransmit-based timeout delivers a data-less established connection, and health checkers/scanners that connect and stay silent hit the same path. (A peer that connects and immediately sends FIN would instead yield `ret == 0` → the "header read insufficient data" branch, not EAGAIN.) 2. **Latent secondary bug (same root cause).** Even when some bytes are present but not the full header, the non-blocking `tcp_read()` returns a short read, hitting the "header read insufficient data" branch (`proxyp.c:85`). A PROXY header split across TCP segments is therefore also rejected. The same applies to the address (`proxyp.c:129`) and options (`proxyp.c:206`) reads. 3. **Suggested fix direction.** Harden `proxyp()` for non-blocking sockets: on `EAGAIN`, `poll()`/`select()` for readability with a bounded timeout and retry; accumulate the header/address/options across partial reads instead of assuming a single `tcp_read()` delivers each field in full. This fixes both the EAGAIN rejection and the split-header rejection, and keeps proxyp() correct for both slapd (blocking) and lloadd (non-blocking) callers. (An alternative — temporarily setting the fd blocking around the proxyp() call in `lload_listener()` — is simpler but blocks the accept thread on a slow/malicious peer and still needs a timeout.) If you nee additional information please let me know. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 9284] New: Need man page for vc contrib overlay
by openldap-its＠openldap.org 21 Oct '26

21 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=9284 Issue ID: 9284 Summary: Need man page for vc contrib overlay Product: OpenLDAP Version: 2.4.50 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: contrib Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- The verified credentials overlay in contrib is missing a man page describing its purpose -- You are receiving this mail because: You are on the CC list for the issue.

1 9

[Issue 9272] New: Invalid search results for subordinate/glued database
by openldap-its＠openldap.org 21 Oct '26

21 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=9272 Issue ID: 9272 Summary: Invalid search results for subordinate/glued database Product: OpenLDAP Version: 2.4.47 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: grapvar(a)gmail.com Target Milestone: --- Here is a trivial test case. Look at the following bunch of glued dit's/databases, declared in this order: | suffix ou=a,ou=1,ou=T # subordinate; contains only one (top-level) entry | suffix ou=2,ou=T # subordinate; contains only one (top-level) entry | suffix ou=b,ou=1,ou=T # subordinate; contains only one (top-level) entry | suffix ou=T # master database, has two entries, top-level | ` ou=1 # ... and this child entry let's query the united database: | $ ldapsearch -b ou=1,ou=T -s sub '' nx | dn: ou=1,ou=T | dn: ou=a,ou=1,ou=T | dn: ou=b,ou=1,ou=T Nice! But wait, what if ... | $ ldapsearch -b ou=1,ou=T -s sub -E\!pr=2/noprompt '' nx | dn: ou=1,ou=T | dn: ou=a,ou=1,ou=T | | # pagedresults: cookie=//////////8= ... BANG! ... | Server is unwilling to perform (53) The problem is the glue_op_search(), which has issues * different parts of code make different assumptions about data structures * different parts of code track state inconsistently * code that looks like a highly probably dead code I mean that likely possible to build another bug-triggering test cases, and glue_op_search() needs not just a fix of the bug above, but intense cleaning and structuring. -- You are receiving this mail because: You are on the CC list for the issue.

1 18

[Issue 9002] Document correct procedure for generating usable backups via slapcat
by openldap-its＠openldap.org 21 Oct '26

21 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=9002 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|2.7.2 |2.7.3 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10217] New: autoca should support more key types
by openldap-its＠openldap.org 21 Oct '26

21 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=10217 Issue ID: 10217 Summary: autoca should support more key types Product: OpenLDAP Version: 2.6.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: enhancement Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- Currently autoca only creates certificates using RSA keypairs. It should at least have an option to use Elliptic Curve keypairs. It probably also needs options to specify other signature algorithms other than the default of SHA256. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10277] New: How to deal with desync between cn=config and back-ldif DNs
by openldap-its＠openldap.org 21 Oct '26

21 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=10277 Issue ID: 10277 Summary: How to deal with desync between cn=config and back-ldif DNs Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- If someone deletes a cn=config entry offline (or through bugs in cn=config, they exist, will file as I isolate), the X-ORDERED RDNs will not be contiguous. cn=config papers over this internally at a cost of never being able to modify the entries affected. Right now the only remedy is slapcat+slapadd of the whole config DB, is that the best we can do? When we detect this (doesn't always happen), should we fix the on-disk copy on startup? -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 8476] slapo-constraint: info per constraint_attribute
by openldap-its＠openldap.org 21 Oct '26

21 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=8476 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|2.7.2 |2.7.3 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8178] back-sock: Timeout to avoid locking
by openldap-its＠openldap.org 21 Oct '26

21 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=8178 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|2.7.2 |2.7.3 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10622] New: pcache: add option to passthru pagedResults searches
by openldap-its＠openldap.org 21 Oct '26

21 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=10622 Issue ID: 10622 Summary: pcache: add option to passthru pagedResults searches Product: OpenLDAP Version: 2.7.0 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: enhancement Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- Currently pcache just silently ignores the pagedResults control, but clients setting the control aren't expecting the unpaged search responses. Add an option for pcache to pass the search through unmodified (and uncached). -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10383] New: slapd-meta ignores olcDbIDAssertBind if olcDbURI defined after it
by openldap-its＠openldap.org 21 Oct '26

21 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=10383 Issue ID: 10383 Summary: slapd-meta ignores olcDbIDAssertBind if olcDbURI defined after it Product: OpenLDAP Version: 2.6.9 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: david.frickert(a)protonmail.com Target Milestone: --- Hi, We are using slapd-meta to connect an OpenLDAP server to another external LDAP server and it works well on first configuration. However, if we want to update any info, e.g. the external LDAP URI, we must replace the olcDbURI attribute. This means that the ordering of the attributes change and this attribute is now defined after olcDbIDAssertBind. Didn't think this would be important, but after this change the "meta" connection stops working and upon enabling debugging i can see that the external LDAP server is responding with: "ldap_bind: Inappropriate authentication (48) additional info: Anonymous Simple Bind Disabled" This seems to imply that the olcDbIDAssertBind attribute is being ignored, likely due to being defined before olcDbURI (my assumption). Is this intended? If so, what can we do to mitigate this problem? Do we need to perform a replace on all attributes of the object to ensure correct ordering, or is there any way to perform an in-place attribute modification without making it shift its position in the object? Example: First configuration (OK): # {0}uri, {2}meta, config dn: olcMetaSub={0}uri,olcDatabase={2}meta,cn=config objectClass: olcMetaTargetConfig olcMetaSub: {0}uri --> olcDbURI: ldap://REDACTED/ou=users,REDACTED olcDbIDAssertBind: bindmethod=simple starttls=yes tls_reqcert=demand binddn="REDACTED" credentials="REDACTED" olcDbRewrite: {0}suffixmassage REDACTED REDACTED olcDbKeepalive: 0:0:0 olcDbBindTimeout: 100000 olcDbCancel: abandon After URI update (NOK): # {0}uri, {2}meta, config dn: olcMetaSub={0}uri,olcDatabase={2}meta,cn=config objectClass: olcMetaTargetConfig olcMetaSub: {0}uri olcDbIDAssertBind: bindmethod=simple starttls=yes tls_reqcert=demand binddn="REDACTED" credentials="REDACTED" olcDbRewrite: {0}suffixmassage REDACTED REDACTED olcDbKeepalive: 0:0:0 olcDbBindTimeout: 100000 olcDbCancel: abandon --> olcDbURI: ldap://REDACTED/ou=users,REDACTED The olcDbURI attribute is shifted to the bottom after a modify operation, and seems to cause these issues. Best Regards, David -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Issue 9596] New: Python test suite
by openldap-its＠openldap.org 21 Oct '26

21 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=9596 Issue ID: 9596 Summary: Python test suite Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- The bash test suite is extremely limited, hard to write for and slow. We can't lose it as it is also portable, but something should be introduced for developers/CI on more modern systems and increase coverage. A Python 3 seed for one is in development in MR!347. -- You are receiving this mail because: You are on the CC list for the issue.

1 12

[Issue 9398] New: Stale accesslog cookie due to unclean shutdown
by openldap-its＠openldap.org 21 Oct '26

21 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=9398 Issue ID: 9398 Summary: Stale accesslog cookie due to unclean shutdown Product: OpenLDAP Version: 2.4.56 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- If slapd terminates uncleanly, a checkpoint will be lost on the accesslog db. Depending on the syncprov overlay checkpoint settings (usually no checkpointing is enabled on the accesslog db) this can cause the system to refuse engage in replication at startup. -- You are receiving this mail because: You are on the CC list for the issue.

1 12

[Issue 10311] New: Work with IETF LDAP working group to update password hashing mechanism RFC
by openldap-its＠openldap.org 21 Oct '26

21 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=10311 Issue ID: 10311 Summary: Work with IETF LDAP working group to update password hashing mechanism RFC Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- Work with the IETF ldap working group to update the RFC to make the suggested hashing mechanism be what is currently "best practice" rather than a specific hashing mechanism. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs