openldap-bugs

openldap-bugs@openldap.org

1 participants
21065 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 10409] New: Implement password policies for the rootdn
by openldap-its＠openldap.org 26 Nov '25

26 Nov '25

https://bugs.openldap.org/show_bug.cgi?id=10409 Issue ID: 10409 Summary: Implement password policies for the rootdn Product: OpenLDAP Version: 2.6.10 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: 31621968(a)qq.com Target Milestone: --- We have successfully configured the Password Policy overlay (ppolicy) on our OpenLDAP server. This configuration ensures that accounts are locked after exceeding the maximum number of failed bind attempts, as defined by the policy. For example, if the ppolicy is set to lock an account after 5 failed bind attempts, the server enforces this behavior effectively for all users under the ppolicy scope. However, we have observed that the rootdn user does not seem to be subject to these same password policies. Specifically, even when the rootdn exceeds the maximum number of failed bind attempts, it does not get locked or restricted in any way. We would like to know if there is a way to apply the same password policies (e.g., account locking after failed bind attempts) to the rootdn. -- You are receiving this mail because: You are on the CC list for the issue.

1 1

[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 10408] New: syncprov_op_search bailout: branch doesn't expect sop removal happened already
by openldap-its＠openldap.org 26 Nov '25

26 Nov '25

https://bugs.openldap.org/show_bug.cgi?id=10408 Issue ID: 10408 Summary: syncprov_op_search bailout: branch doesn't expect sop removal happened already 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: --- There are codepaths in syncprov_op_search that reach 'bailout:' when it's possible for syncprov_op_abandon to have snuck in and remove the 'syncops *' from the list in the meantime. However this branch always expects to find it there. Fix is coming. -- You are receiving this mail because: You are on the CC list for the issue.

1 1

[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 6938] Windows IPv6 support
by openldap-its＠openldap.org 25 Nov '25

25 Nov '25

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

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs