openldap-bugs November 2023

openldap-bugs@openldap.org

1 participants
209 discussions

[Issue 10065] New: slapd needs a config option for the ssf of an external security proxy using "proxy protocol v2"
by openldap-its＠openldap.org 14 Nov '23

14 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=10065 Issue ID: 10065 Summary: slapd needs a config option for the ssf of an external security proxy using "proxy protocol v2" Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: sean(a)teletech.com.au Target Milestone: --- Commit 146889f introduced support for the haproxy "proxy protocol v2". A very welcome addition that allows an external security layer to be implemented. This implementation is however somewhat hobbled. Cyrus SASL uses "Security Strength Factors" or "ssf" to determine what Authentication mechanisms to offer. slapd conveys the implicit security of UNIX domain sockets to the SASL layer by specifying a non-zero ssf for these connections. This can be configured with the "olcLocalSSF" config setting. For implicit/explicit TLS connections, the "olcSecurity: tls=<n>" provides the cryptographic strength of the TLS layer to the SASL layer. For an external TLS-terminating proxy, there does not appear to be any way to inform Cyrus SASL of the presence of TLS security on these proxied connections. The outcome of this is that PLAIN and EXTERNAL authentication mechanisms are not offered to clients connecting through the secure proxy. This can be overcome by weakening the security properties of the SASL layer with the olcSaslSecProps configuration option, but this weakening will apply to all clients, not just clients connecting via the secure proxy. What is required is some way to tell slapd and it's integrated SASL layer about the presence of TLS encryption on the proxy's input. As a precaution, this might be restricted to slapd connections in the 127.0.0.0/8 [IPv6:::] address ranges. -- You are receiving this mail because: You are on the CC list for the issue.

2 29

[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 10128] New: Unavailability of OpenSSL 3.X compatible openldap lib libldap_r.so
by openldap-its＠openldap.org 14 Nov '23

14 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=10128 Issue ID: 10128 Summary: Unavailability of OpenSSL 3.X compatible openldap lib libldap_r.so Product: OpenLDAP Version: 2.6.0 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: umakanta.senapati(a)netwitness.com Target Milestone: --- Hi Team, We are looking for openldap lib libldap_r.so compatible with openssl 3.x for el8 platform. From the release note i could check Open ldap has added openSSL 3.X support from version 2.5X onwards. But we couldn’t find any open ldap el8 rpm available with OpenSSL3.X support for 2.5.x or higher version. Please correct me if my understanding is wrong. Is there any plan to provide open ldap el8 rpm with libldap_r.so compatible with Openssl 3.X. Please help me if i can build the open ldap libldap_r.so with opensll 3.x lib or not? If yes please share the guide lines for the same. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10099] New: OpenLDAP version 2.5 & 2.6 causes IP connectivity to break and breaks basic commands like reboot
by openldap-its＠openldap.org 09 Nov '23

09 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=10099 Issue ID: 10099 Summary: OpenLDAP version 2.5 & 2.6 causes IP connectivity to break and breaks basic commands like reboot Product: OpenLDAP Version: 2.5.16 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: amcwongahey(a)rbbn.com Target Milestone: --- Created attachment 980 --> https://bugs.openldap.org/attachment.cgi?id=980&action=edit The package Makefile I am upgrading openLDAP from version 2.4.59 to 2.5.16 and am running into show stopper issues. In my environment I am running CLIENT mode only (libldap). I have tried 2.5.16 with the following combinations: openSSL version 1.1.1s and 3.0.8 Kernel versions: 5.4.92, 4.19.192 and 2.6.32 Problems described below ONLY happens when connecting with a domain controller using LDAPS - does NOT happen with LDAP (non-secure). When I use ANY combination that includes kernel version 4 or 5 along with openLDAP 2.5.16 I get random lockups to the point where IP connectivity breaks into and out of the node. And also it is so completely hosed that even issuing a reboot command from the console completely hangs and does not restart the node. The problem happens roughly 50% of the time with openLDAP combined with version 5 kernel but happens noticeably less frequently with the version 4 kernel. As soon as I kill the process that invokes the connection with openLDAP the problem clears up. I invoke the connection with the following function call: nReturnCode = ldap_sasl_bind( m_pLD, m_ADBind.GetBindDN(), LDAP_SASL_SIMPLE, &stPassword, NULL, NULL, &nMsgID); I use simple auth simply because the entire connection is secured with TLS anyway and there is another functional reason which I cannot go into details on. OpenLDAP never returns from the ldap_sasl_bind function call. It hangs somewhere inside the library but that alone cannot account for the complete lockup where basic commands like reboot, etc do not work and where all IP connectivity breaks. It seems it has to be something with openLDAP and the Linux kernel combined that triggers this issue. I am hoping that someone who is much more familiar with the libldap part of the library will pick up on this and be able to determine how to fix this. As an FYI: I also tried the very first version of 2.5.1 (alpha release) and the latest 2.6 and the problem happens on those versions as well. To be clear the problem does NOT happen if I run openLDAP 2.5.16 with Linux kernel version 2.6.32. ADDITIONALLY ALL openSSL & kernel combinations works with openLDAP version 2.4.59! I am attaching the package Makefile to this report. Below is the ldap.conf contents: TLS_REQCERT never TLS_KEY /tmp/ssl/certs/server.pem TLS_CERT /tmp/ssl/certs/server.pem TLS_PROTOCOL_MIN 3.1 sasl_secprops maxssf=0 -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Issue 9009] 2.7: Switch to LMDB v1.0
by openldap-its＠openldap.org 07 Nov '23

07 Nov '23

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

1 0

[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

[Issue 9341] New: Delta-sync MPR needs to be stable regardless of ordering
by openldap-its＠openldap.org 07 Nov '23

07 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=9341 Issue ID: 9341 Summary: Delta-sync MPR needs to be stable regardless of ordering Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: replication Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- If two or more updates are spread across several providers before they have a chance to learn about the others, all replicas need to arrive at the same content regardless of the order in which they arrive. One example that is broken at the moment: - (csn a) server 1 accepts a modify - (csn b) server 2 accepts a delete on the same DN - (csn c) server 2 accepts an add on that DN again If a replica receives the actions in the order bca vs. abc, the content of the entry will be different even though the final CSN set is the same -> they will never converge. The ordering 'bac' also needs to result in eventual convergence, even if it means a refresh or replication from either provider stalling temporarily? Merge request with this test case (so far): https://git.openldap.org/openldap/openldap/-/merge_requests/145 -- You are receiving this mail because: You are on the CC list for the issue.

1 11

[Issue 9547] New: OpenLDAP does not send port as SPN when authenticating SASL GSSAPI
by openldap-its＠openldap.org 07 Nov '23

07 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=9547 Issue ID: 9547 Summary: OpenLDAP does not send port as SPN when authenticating SASL GSSAPI Product: OpenLDAP Version: 2.4.44 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: robert.wilson1717(a)gmail.com Target Milestone: --- When trying to authenticate to an ADLDS server using kerberos and a MIT ccache, OpenLdap only passes the hostname to the SASL mechanism, causing a mismatch between the SPN in the client "ldap/adlds.my.domain" and the one registered in AD "ldap/adlds.my.domain:50000" Is there a way fo forcing OpenLDAP to pass the port as part of the SASL request? Or is there a part of the OpenLDAP -> Cyprus-SASL -> MIT KRB5 chain where this can be enabled? -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 9506] New: dynlist: member expansion when member attribute not requested
by openldap-its＠openldap.org 07 Nov '23

07 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=9506 Issue ID: 9506 Summary: dynlist: member expansion when member attribute not requested Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- When configured to do dynamic "member" expansion, i.e.: overlay dynlist dynlist-attrset groupOfURLs memberURL member Any query against an object that would trigger this expansion will incur a penalty while dynlist does the expansion work even if there was no request for the member attribute. Currently that can be worked around by specifying the manageDSAit control when doing a search on the object, but this may not be feasible for some client applications and additionally other directory servers do not do this expansion for their dynamic group implementations unless the underlying configured attribute is explicitly requested. We've already implemented this in dynlist for the memberOfAD case, we should do it here as well. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9269] New: "hidden" "subordinate" database is shown in a directory tree
by openldap-its＠openldap.org 07 Nov '23

07 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=9269 Issue ID: 9269 Summary: "hidden" "subordinate" database is shown in a directory tree Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: grapvar(a)gmail.com Target Milestone: --- "hidden" configuration option is ignored by slapd (not honored by "glue" overlay?) if the database it tries to hide is also a "subordinate" database. Checked for openldap 2.4.47 and current git master (f3952d9). -- You are receiving this mail because: You are on the CC list for the issue.

1 9

← Newer
1
...
14
15
16
17
18
19
20
21
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 November 2023