openldap-bugs June 2026

openldap-bugs@openldap.org

1 participants
209 discussions

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

08 Sep '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 7

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

08 Sep '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 11

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

08 Sep '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 11

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

08 Sep '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 29

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

08 Sep '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 4

[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 08 Sep '26

08 Sep '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 7

[Issue 10282] New: MSVC builds are not supported
by openldap-its＠openldap.org 08 Sep '26

08 Sep '26

https://bugs.openldap.org/show_bug.cgi?id=10282 Issue ID: 10282 Summary: MSVC builds are not supported Product: OpenLDAP Version: 2.5.18 Hardware: All OS: Windows Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: cmb(a)php.net Target Milestone: --- I'm a maintainer of an OpenLDAP port[1] which is used to build liblber and libldap for PHP on Windows. So far this uses hand-made configuration and Visual Studio solutions, but that is not sustainable in the long run. Instead, I'd rather like to use the autotools based build chain with MSYS2 (or Cygwin), but still using the MSVC build tools (cl.exe, link.exe, etc.) and the MS Windows SDK for best compatibility with other builds for PHP on Windows. Apparently, this is not yet supported by OpenLDAP (2.5.18). I've managed to add some patches[2] to get where I'd like this to go[3]. Some of the patches are highly PHP (BC) specific, some are just quick hacks (because I don't know better), but some appear to be appropriate for inclusion into the OpenLDAP sources. Are you generally interested in supporting MSVC tools and MS Windows SDKs? If so, what would be the best way to contribute -- sending MRs to the repo[4]? Should these tackle individual issues, or rather be complete (note that I'm likely not able to provide a full-fledged solution due to my very limited knowledge of autotools and Linux, and limited time). [1] <https://github.com/winlibs/openldap> [2] <https://github.com/winlibs/openldap/tree/cmb/2.5.18> [3] <https://github.com/cmb69/winlib-builder/actions/runs/11713086509> [4] <https://git.openldap.org/openldap/openldap> -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10510] New: write_coherence can assert() on unbind
by openldap-its＠openldap.org 17 Aug '26

17 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=10510 Issue ID: 10510 Summary: write_coherence can assert() on unbind 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: --- If lloadd links a client with a backend and that client issues a write and unbind in quick succession, the self-checks in client_reset are overly strict, triggering an assert. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9786] New: liblber: missing export of ber_pvt_wsa_err2string
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=9786 Issue ID: 9786 Summary: liblber: missing export of ber_pvt_wsa_err2string Product: OpenLDAP Version: 2.6.1 Hardware: All OS: Windows Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: tobias.junghans(a)veyon.io Target Milestone: --- When building (cross-compiling) OpenLDAP via GCC/mingw-w64, an undefined reference to ber_pvt_wsa_err2string() is reported when libldap.dll is linked. This can be fixed easily by adding ber_pvt_wsa_err2string() to libraries/liblber/lber.map -- You are receiving this mail because: You are on the CC list for the issue.

1 10

[Issue 9816] New: slapcat cordeumps during mdb subtree dump with -s
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=9816 Issue ID: 9816 Summary: slapcat cordeumps during mdb subtree dump with -s Product: OpenLDAP Version: 2.5.11 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: khoffmann(a)united-internet.de Target Milestone: --- Created attachment 887 --> https://bugs.openldap.org/attachment.cgi?id=887&action=edit gdb backtrace of slapcat run When trying to use slapcat in combination with -b and -s in order to create a LDIF backup of a mdb subtree, slapd crashes with a coredump (please see the attached snippet with gdb output from a reproduced test tree). The problem was reporducible with different mdb databases / suffixes and only appears with option -s. The same dump with -H 'ldap:///ou=users,o=company,c=de??sub?' instead of -s ou=users,o=company,c=de works perfectly fine, as long as the "attrs part" is empty in the ldap-uri. Also using slapcat with -b only (for a full database dump) works fine as well. I'm aware of the fact that -s option is marked as DEPRECATED - I'm not sure if you are going to fix this bug or if you rather take the change to remove the option completely from future major versions. Please let me also know if it's expected behaviour that the -H option doesn't work whenever the attribute part isn't empty and if I should contribute to a documentation update for this edge case. Best regards, Kris -- You are receiving this mail because: You are on the CC list for the issue.

1 6

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs June 2026