openldap-bugs February 2023

openldap-bugs@openldap.org

2 participants
190 discussions

[Issue 9813] New: Incompatibility between remoteauth and ppolicy overlays
by openldap-its＠openldap.org 17 Sep '24

17 Sep '24

https://bugs.openldap.org/show_bug.cgi?id=9813 Issue ID: 9813 Summary: Incompatibility between remoteauth and ppolicy overlays Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: thierry.pubellier(a)paris.fr Target Milestone: --- Hi, We are planning to use OpenLDAP as a proxy for some users in our Active Directory servers, using remoteauth overlay. We want this OpenLDAP instance to also implement an account lockout policy, preventing the lockout on our internal Active Directory servers. But there seems to be an incompatibility between remoteauth and ppolicy overlays : remoteauth won't remote authenticate a user if local userPassword attribute exists, while ppolicy overlay needs this attribute. Could there be a configuration parameter in ppolicy to allow lockout checks/modifications (which seemed to be the default behavior of OpenLDAP before ITS#7089) ? I can provide a patch if allowed. Thanks by advance, Best regards, Thierry -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 9921] New: Tautology in clients/tools/common.c:print_vlv()
by openldap-its＠openldap.org 08 May '24

08 May '24

https://bugs.openldap.org/show_bug.cgi?id=9921 Issue ID: 9921 Summary: Tautology in clients/tools/common.c:print_vlv() Product: OpenLDAP Version: 2.6.3 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: client tools Assignee: bugs(a)openldap.org Reporter: dpa-openldap(a)aegee.org Target Milestone: --- https://git.openldap.org/openldap/openldap/-/blob/master/clients/tools/comm… contains: tool_write_ldif( ldif ? LDIF_PUT_COMMENT : LDIF_PUT_VALUE, ldif ? "vlvResult" : "vlvResult", buf, rc ); The second parameter is always vlvResult, irrespective of the value of ldif. -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Bug 9193] New: HTML in mailing list description
by openldap-its＠openldap.org 19 Mar '24

19 Mar '24

https://bugs.openldap.org/show_bug.cgi?id=9193 Bug ID: 9193 Summary: HTML in mailing list description Product: website Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: website Assignee: bugs(a)openldap.org Reporter: ryan(a)openldap.org Target Milestone: --- e.g. https://lists.openldap.org/postorius/lists/openldap-devel.openldap.org/ contains code for links and formatting, but all inside of a <pre> block. -- You are receiving this mail because: You are on the CC list for the bug.

1 5

[Issue 9823] New: syncprov doesn't fallback when deltasync consumer's offline beyond accesslog depth
by openldap-its＠openldap.org 15 Feb '24

15 Feb '24

https://bugs.openldap.org/show_bug.cgi?id=9823 Issue ID: 9823 Summary: syncprov doesn't fallback when deltasync consumer's offline beyond accesslog depth Product: OpenLDAP Version: 2.6.1 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: smckinney(a)symas.com Target Milestone: --- Configured w/ deltasync. When a consumer goes offline for a duration exceeding the the logpurge interval, won't fallback into syncrepl, resulting in a dsync. -- You are receiving this mail because: You are on the CC list for the issue.

1 17

[Issue 9795] New: Remove memberof overlay
by openldap-its＠openldap.org 01 Feb '24

01 Feb '24

https://bugs.openldap.org/show_bug.cgi?id=9795 Issue ID: 9795 Summary: Remove memberof overlay Product: OpenLDAP Version: 2.6.1 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: --- The memberof overlay was deprecated with the release of OpenLDAP 2.5. It should be removed prior for the next minor release (i.e., 2.7) -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10014] New: TLS handle using MbedTLS
by openldap-its＠openldap.org 30 Jan '24

30 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=10014 Issue ID: 10014 Summary: TLS handle using MbedTLS Product: OpenLDAP Version: 2.6.4 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: contrib Assignee: bugs(a)openldap.org Reporter: johan.pascal(a)linphone.org Target Milestone: --- Created attachment 950 --> https://bugs.openldap.org/attachment.cgi?id=950&action=edit Add a TLS handle using MbedTLS Hi, I wrote a TLS handle based on MbedTLS. I attach the patch here but I can also put in on gitlab and make a merge request there. The patch contains the minimal modifications to build openldap using MbedTLS as backend for TLS. You must run aclocal, autoheader amd autoconf to regenerate the archived aclocal.m4, configure and include/portable.hin files. This contribution was originally written for the linphone project, and copyright belongs to Belledonne Communications SARL. The attached file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch were developed by Belledonne Communications SARL. Belledonne Communications SARL has not assigned rights and/or interest in this work to any party. I, Johan Pascal am authorized by Belledonne Communications, my employer, to release this work under the following terms. The attached modifications to OpenLDAP Software are subject to the following notice: Copyright 2010-2023 Belledonne Communications SARL Redistribution and use in source and binary forms, with or without modification, are permitted only as authorized by the OpenLDAP Public License. -- You are receiving this mail because: You are on the CC list for the issue.

1 18

[Issue 9944] New: Reverting an olcDbACLBind statement breaks proxied write operations
by openldap-its＠openldap.org 16 Jan '24

16 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=9944 Issue ID: 9944 Summary: Reverting an olcDbACLBind statement breaks proxied write operations Product: OpenLDAP Version: 2.6.3 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: --- On a system with olcDbIDAssertBind configured, and proxied authorizations working correctly, an olcDbACLBind statement was added to the configuration for lastbind support. However an incorrect identity was in place for the authzid in the ACL bind statement which caused proxy authorization to fail. The change was backed out (There was never any change to the olcDbIDAssertBind config fragment) and after that, all write operations failed instead of being proxied, with err=80. Restarting slapd fixed the issue, which indicates an underlying problem in the cn=config db in reverting to the original working state. -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Issue 9719] New: refreshOnly sends empty cookie when client up to date
by openldap-its＠openldap.org 16 Nov '23

16 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=9719 Issue ID: 9719 Summary: refreshOnly sends empty cookie when client up to date 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: --- Syncprov will send an empty cookie if the consumer has the same cookie as provider. To the best of my knowledge this is not in line with RFC4533 and consumers would effectively drop their cookie when the search finishes. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 9677] New: Create "make install-strip” target
by openldap-its＠openldap.org 14 Nov '23

14 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=9677 Issue ID: 9677 Summary: Create "make install-strip” target Product: OpenLDAP Version: 2.5.7 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: dpa-openldap(a)aegee.org Target Milestone: --- All open source make-based projects shall follow the same naming and semantics of targets, described at https://www.gnu.org/prep/standards/html_node/Standard-Targets.html . In particular “make install-strip” shall strip the binaries during the installation, while “make install” shall not strip them. In openldap currently “make install” does strip, which surprised me. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 9580] New: Refresh vs. accesslog in delta-MPR
by openldap-its＠openldap.org 07 Nov '23

07 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=9580 Issue ID: 9580 Summary: Refresh vs. accesslog in delta-MPR Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: replication Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- A server consuming a plain syncrepl session (might be a delta-MMR refresh) still has to log the entries into accesslog, however that accesslog stops being capable of serving as a delta-sync source: - operation entryCSNs will be out-of-order - the changes logged will not be the intended modifications (e.g. if we fell back after a conflict, the conflicting entry will be replaced with the other version, other examples available) We need to deal with that somehow, at the very least we need to make sure the consumer will not take them at face value. We could record this in the accesslog root entry if we can detect when this starts and match it up with the final cookie, syncprov would still need some tweaks to understand it. We could mark the entries received this way and make sure delta-consumers treat them as "poison", as if they were running a plain syncrepl session themselves (not update contextCSN until that's finished, mark its own accesslog entries this way, ...). Anything like that needs guarantees that it will clean itself up once all of the real plain sessions finish otherwise we've lost delta-sync altogether. A different approach might or might not be needed for live delta-persist sessions replicating from a refreshing provider, but at least that syncprov has a way of detecting this live if it chooses to. -- You are receiving this mail because: You are on the CC list for the issue.

1 13

← Newer
1
...
7
8
9
10
11
12
13
...
19
Older →

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 February 2023