openldap-bugs October 2025

openldap-bugs@openldap.org

1 participants
38 discussions

[Issue 10383] New: slapd-meta ignores olcDbIDAssertBind if olcDbURI defined after it
by openldap-its＠openldap.org 28 Nov '25

28 Nov '25

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 3

[Issue 10286] New: ldap_pvt_gettime may result in "not new enough csn" problems in multi-thread case.
by openldap-its＠openldap.org 27 Nov '25

27 Nov '25

https://bugs.openldap.org/show_bug.cgi?id=10286 Issue ID: 10286 Summary: ldap_pvt_gettime may result in "not new enough csn" problems in multi-thread case. Product: OpenLDAP Version: 2.6.6 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: 971748261(a)qq.com Target Milestone: --- Created attachment 1041 --> https://bugs.openldap.org/attachment.cgi?id=1041&action=edit the log of adding two entry which shows the time sequence. I used openldap as krb5's database, and openldap was deploymented in mirrormode. I tried to add kerberos principals via kadmin.local -q "addprinc -randkey principal. slapd log showed that the entry of kadmin/admin was added earlier than the entry of ossuser. But the csn of kadmin/admin was greater than ossuser. In this case, when the two entry began to sync to the other slapd server, ossuser was ignored because of "csn not new enough" -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10293] New: Log operations generated by syncrepl at STATS level
by openldap-its＠openldap.org 26 Nov '25

26 Nov '25

https://bugs.openldap.org/show_bug.cgi?id=10293 Issue ID: 10293 Summary: Log operations generated by syncrepl at STATS level 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: --- Similarly to how incoming operations are logged, operations created by syncrepl should be logged as well. -- You are receiving this mail because: You are on the CC list for the issue.

1 14

[Issue 10398] New: memberof and refint clash on subtree renames
by openldap-its＠openldap.org 25 Nov '25

25 Nov '25

https://bugs.openldap.org/show_bug.cgi?id=10398 Issue ID: 10398 Summary: memberof and refint clash on subtree renames Product: OpenLDAP Version: 2.6.10 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- If a group and its members are under a subtree that got renamed, refint will trigger, and try to update all the relevant DNs. When it processes the group entry, it will issue Modifies to update the DNs of the group's members. The memberof overlay will see these modifies and start trying to update the corresponding memberof values but will only succeed halfway. It will try to delete the old memberof value from the old member DN's entry, which fails because the subtree has renamed all the entries. Then it will try to add the new memberof value to the new member DN's entry, which succeeds. Then eventually refint will try to process the member's. It will try to delete the old memberof value from the new entry, and add the new memberof value to the entry. This modify request fails because the new value is already present. The entry is left with a memberof value that points to the obsolete group DN. The solution is for refint to set the manageDsaIt control on its repair ops, and for memberof to ignore Modify requests with this control set. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10329] New: Additional issues with pcache, and a test
by openldap-its＠openldap.org 25 Nov '25

25 Nov '25

https://bugs.openldap.org/show_bug.cgi?id=10329 Issue ID: 10329 Summary: Additional issues with pcache, and a test Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: aweits(a)rit.edu Target Milestone: --- Created attachment 1062 --> https://bugs.openldap.org/attachment.cgi?id=1062&action=edit test & patches Hello again! Further testing revealed some more issues in pcache [re: ITS#10270]. I've attached an update to test020-proxycache as well. These are based off the current git HEAD. -- You are receiving this mail because: You are on the CC list for the issue.

1 11

[Issue 10026] New: Refresh handling can skip entries (si_dirty not managed properly)
by openldap-its＠openldap.org 25 Nov '25

25 Nov '25

https://bugs.openldap.org/show_bug.cgi?id=10026 Issue ID: 10026 Summary: Refresh handling can skip entries (si_dirty not managed properly) Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- Take MPR plain syncrepl with 3+ providers. When a provider's own syncrepl session transitions to persist and a it starts a new parallel session towards another host, that session always has to start as a refresh. If that refresh serves entries to us, our handling of si_dirty is not consistent: - if the existing persist session serves some of these entries to us, we can "forget" to pass the others to a newly connected consumer - same if the refresh is abandoned and we start refreshing from a different provider that might be behind what we were being served (again our consumers could suffer) - if we restart, si_dirty is forgotten and our consumers suffer even worse We might need to be told (at the beginning of the refresh?) what the end state we're going for is, so we can keep si_dirty on until then. And somehow persist that knowledge in the DB... -- You are receiving this mail because: You are on the CC list for the issue.

1 18

[Issue 9717] New: The RADIUSOV overlay can be incorporated into OpenLDAP
by openldap-its＠openldap.org 25 Nov '25

25 Nov '25

https://bugs.openldap.org/show_bug.cgi?id=9717 Issue ID: 9717 Summary: The RADIUSOV overlay can be incorporated into OpenLDAP Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: contrib Assignee: bugs(a)openldap.org Reporter: rdubner(a)symas.com Target Milestone: --- -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10363] New: Implement a target connection time-to-live in asyncmeta
by openldap-its＠openldap.org 25 Nov '25

25 Nov '25

https://bugs.openldap.org/show_bug.cgi?id=10363 Issue ID: 10363 Summary: Implement a target connection time-to-live in asyncmeta Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: nivanova(a)symas.com Target Milestone: --- Implement a feature that limits the maximum time before a target connection is reset, even if it is not idle - conn-ttl. To avoid too many target connections timing out at once, a minimum reset interval per target should also be configurable. So, a configuration of: conn-ttl 5s 5s would mean connections have a 5 seconds time-to-live, but a connection should be reset no more frequently that once every 5 seconds per target. This feature was requested by a customer. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 9731] New: startup messages still go to syslog when logfile-only is on
by openldap-its＠openldap.org 25 Nov '25

25 Nov '25

https://bugs.openldap.org/show_bug.cgi?id=9731 Issue ID: 9731 Summary: startup messages still go to syslog when logfile-only is on Product: OpenLDAP Version: 2.6.0 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- When setting logfile-only on, slapd still logs its startup message to syslog: Oct 29 21:07:47 u18test slapd[18534]: @(#) $OpenLDAP: slapd 2.6.0 (Oct 29 2021 05:12:17) $#012#011openldap This is useful information to have consolidated into the specified logfile. Note that: 617c62a3.16f03fdb 0x7f9325ed67c0 slapd starting does make it to the logfile. However, it would be useful to have the build date and version in the specified logfile. -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 10380] New: file logger doesn't emit slapd startup/version info
by openldap-its＠openldap.org 25 Nov '25

25 Nov '25

https://bugs.openldap.org/show_bug.cgi?id=10380 Issue ID: 10380 Summary: file logger doesn't emit slapd startup/version info 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: --- When using syslog, a startup message is emitted which is useful in many different contexts: - signals a slapd restart to the admin - shows the actual version used - if a crash happened just before, there is no "stopped" message, this is a hint to anyone looking that something was not right and the slapd is not the same process - people writing log processing scripts (incident response) know when it's necessary to reset their state, again as it's a new process Because of the above, it feels like a regression to me. I guess we can just emit this info on logfile config handlers? This means startups and logfile switches are still handled as they used to in syslog and log rotation doesn't emit anything (making it easy and safe to just concatenate files). Yes, slapd logs its PID in most formats so restarts can be detected that way, but that's considerably harder to search for. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs October 2025