openldap-bugs October 2026

openldap-bugs@openldap.org

1 participants
73 discussions

[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

[Issue 10528] New: core.ldif fails to load via "include:" in cn=config on Symas OpenLDAP 2.6.13-3 (RHEL 9)
by openldap-its＠openldap.org 21 Oct '26

21 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=10528 Issue ID: 10528 Summary: core.ldif fails to load via "include:" in cn=config on Symas OpenLDAP 2.6.13-3 (RHEL 9) Product: OpenLDAP Version: 2.6.13 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: lucas.vicente(a)ebz.tec.br Target Milestone: --- Hello, We are experiencing an issue while trying to load the core.ldif schema default using the dynamic configuration (cn=config). When using the following in my LDIF: include: file:///opt/symas/etc/openldap/schema/core.ldif I get this error: olcAttributeTypes: value #48 olcAttributeTypes: Unexpected token before MUST c MAY ( searchGuide $ description ) ) slapadd: could not add entry dn="cn={0}core,cn=schema,cn=config" (line=14): olcAttributeTypes: Unexpected token before MUST c MAY ( searchGuide $ description ) ) Obs: If I create a slapd.conf that includes the core schema and run: slaptest -f slapd.conf -F /tmp/slapd.d It works without errors. However, when trying to load the same schema using slapadd + include: in cn=config, it fails. For reference, I tested the same steps on version 2.6.10 and it worked without errors. Steps to reproduce: Install Symas OpenLDAP 2.6.13 on RHEL 9 Try to load the core schema using: dn: cn=schema,cn=config objectClass: olcSchemaConfig cn: schema include: file:///opt/symas/etc/openldap/schema/core.ldif Would you be able to verify this behavior? Thanks! -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 10423] New: It is possible via cn=config to add an entry of one database type with the object class of another, causing OpenLDAP to crash
by openldap-its＠openldap.org 21 Oct '26

21 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=10423 Issue ID: 10423 Summary: It is possible via cn=config to add an entry of one database type with the object class of another, causing OpenLDAP to crash Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: nivanova(a)symas.com Target Milestone: --- This happens specifically because the user by mistake attempts to create a meta database by specifying the object class for back-ldap. Since these share a lot of common attributes, schema checks do not fail. As a result, slapd initializes a meta database (based on olcDatabase value), but attempts to manipulate an initialized back-ldap database after that, and segfaults. Like this: dn: olcDatabase=meta,cn=config objectClass: olcDatabaseConfig objectClass: olcLDAPConfig olcDatabase: meta olcDbURI: "ldap://example.com" While it seems this is only possible for the proxy databases, we cannot rely that schema checks on attributes will fail for other database combinations, who knows what common attributes can be added or supplied in the future, we we have to fix this. The issue is reproducible via slapadd and at runtime with ldapadd. -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Issue 10641] New: Missing bound check on X.509 SAN string before wildcard matching
by openldap-its＠openldap.org 21 Oct '26

21 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=10641 Issue ID: 10641 Summary: Missing bound check on X.509 SAN string before wildcard matching Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: xfding(a)google.com Target Milestone: --- In tls_o.c:1082, https://git.openldap.org/openldap/openldap/-/blob/master/libraries/libldap/… (sn[0] == '*') && (sn[1] == '.') was tested before checking ( sl > 1 ) Similarly, on 1191, https://git.openldap.org/openldap/openldap/-/blob/master/libraries/libldap/… ( cnstr[0] == '*' ) && ( cnstr[1] == '.' ) also has a missing bound check ( cnlen > 1 ) Note that OpenSSL would stop null-terminating strings by default in the major releases. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10639] New: Change --enable-balancer to default to mod
by openldap-its＠openldap.org 21 Oct '26

21 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=10639 Issue ID: 10639 Summary: Change --enable-balancer to default to mod Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: lloadd Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- Preferably in 2.7.x as well but that will need an admin guide entry. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10640] New: paged results requests with size 0 are undefined in RFC2696
by openldap-its＠openldap.org 21 Oct '26

21 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=10640 Issue ID: 10640 Summary: paged results requests with size 0 are undefined in RFC2696 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: --- Apart from "abandoning" the paged result state (and even then, there's no indication what the result should be), the behaviour for a cookie-less paged search with size is completely unspecified. We should probably reject that on parsing. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 10645] New: ldapsearch -E vlv behaviour is near useless
by openldap-its＠openldap.org 21 Oct '26

21 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=10645 Issue ID: 10645 Summary: ldapsearch -E vlv behaviour is near useless Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: client tools Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- It pretends to walk the filter when asked to continue but there are issues: - there is no way to stop it (EOF is the same as Enter and no other options available) - setting "after" count to 0 has it keep issuing the same search over and over - no end of list detection, so it happily overshoots and then fails with rangeError - ignores the returned position that the server sent so can't resume after re-positioning (e.g. with value based search) -- You are receiving this mail because: You are on the CC list for the issue.

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs October 2026