openldap-bugs March 2020

openldap-bugs@openldap.org

9 participants
1404 discussions

[Bug 9198] New: libraries: memory leak in UTF8bvnormalize()
by openldap-its＠openldap.org 28 Apr '20

28 Apr '20

https://bugs.openldap.org/show_bug.cgi?id=9198 Bug ID: 9198 Summary: libraries: memory leak in UTF8bvnormalize() Product: OpenLDAP Version: 2.4.49 Hardware: All OS: Linux Status: UNCONFIRMED Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: 1259039012(a)qq.com Target Milestone: --- -- You are receiving this mail because: You are on the CC list for the bug.

1 14

[Bug 9188] New: Expose transaction mt_flags?
by openldap-its＠openldap.org 10 Apr '20

10 Apr '20

https://bugs.openldap.org/show_bug.cgi?id=9188 Bug ID: 9188 Summary: Expose transaction mt_flags? Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: code(a)doriantaylor.com Target Milestone: --- Created attachment 631 --> https://bugs.openldap.org/attachment.cgi?id=631&action=edit patch in mdb_txn_flags I have taken over maintenance of the Ruby bindings to LMDB (https://github.com/doriantaylor/lmdb/tree/reconcile-2.7) and am currently fleshing out the transaction code. What I am finding is something of a leaky abstraction: in the current configuration it is essentially too easy to write Ruby code that messes up the internal transaction bookkeeping of the binding. I am still trying to get my bearings on both the binding and the LMDB library itself, but it seems it would be generally useful if it was possible to determine whether a given transaction was read-only, so for example to prevent one from opening a read-write transaction beneath a read-only one. As such, I propose the enclosed patch that adds an `mdb_txn_flags` function, which returns the `mt_flags` field. This would enable downstream developers to tell if a given transaction was, among other things, read-only, and behave accordingly. -- You are receiving this mail because: You are on the CC list for the bug.

1 2

[Bug 9196] New: Problem using ldapsearch across forests with trust
by openldap-its＠openldap.org 01 Apr '20

01 Apr '20

https://bugs.openldap.org/show_bug.cgi?id=9196 Bug ID: 9196 Summary: Problem using ldapsearch across forests with trust Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: client tools Assignee: bugs(a)openldap.org Reporter: kleber.s.carvalho(a)avanade.com Target Milestone: --- Created attachment 695 --> https://bugs.openldap.org/attachment.cgi?id=695&action=edit Problem using ldapsearch across forests with trust Hello, We are in a project where the client has an application developed in Java that has a library developed by the client himself that uses the openldap tool to authenticate users that exist in the minca.com domain. However, this company is undergoing a drastic business change and this minca.com domain that belongs only in one forest must have a one-way trust relationship with another forest called klabs.com and its respective domains children (subtree), the general drawing can be checked in the file 1_forest_trust.pdf. The trust relationship between the two forests was successfully carried out as can be seen in the files 2_trust_minca.JPG and 3_trust_klabs.JPG A user named minca was created in the minca.com domain, that is, minca(a)minca.com according to files 4_mincauser_1.JPG and 4_mincauser_2.JPG (to observe the SID). Meanwhile, in the domain child.klabs.com, the group CHILDADMINS was created and the user minca from the forest minca.com was successfully added according to file 5_childadminsgroup.JPG. First, we performed a valid test by performing authentication and a simple query directly to the minca.com domain, with the command: ldapsearch -H 'LDAP: //minca.com: 3268' -D 'cn = Administrator, cn = users, dc = minca, dc = with' -w Avanade @ 2020! -b 'cn = users, dc = minca, dc = com' According to the 6_openldap_direct_sucess.JPG file, it is possible to observe that the result became what was expected. However, when performing this procedure and authenticating the user minca(a)minca.com in the child.klabs.com domain using the ldapsearch tool, the result was an error according to file 7_openldaperror_indirectaccess.JPG stating invalid credentials In addition, searching the internet, we verified that the LDAP call should be LDAP: //child.klabs.com/dc=minca,dc=com, however, ldapsearch returned PARSE LDAP URI (s) error, as per file 8_openldaperror_parse.JPG. However, a .net application was created to perform this same function and it worked, as per file 9_dotNetApp_success.JPG After that, we tried to understand if the openldap tool would be able to perform the same action on the same tree (subtree) and we obtained the expected success result according to the file 10_openldap_subtree_success.JPG So, we tried to list the members of the CHILDADMINS group that are in the child.klabs.com domain and have as a member a user from the minca.com forest, using the command: ldapsearch -H 'LDAP: //child.klabs.com: 3268' -D 'cn = Administrator, cn = users, dc = child, dc = klabs, dc = with' -w Avanade @ 2020! -b 'cn = CHILDADMINS, cn = users, dc = child, dc = klabs, dc = com' and it was observed that openldap I find the user in question bringing his SID according to the figure 11_openldap_GroupMemberOf_SSID.JPG and, afterwards with a treatment in the openldap tool itself through the command: ldapsearch -H 'LDAP: //child.klabs.com: 3268' -D 'cn = Administrator, cn = users, dc = child, dc = klabs, dc = with' -w Avanade @ 2020! -b "cn = ForeignSecurityPrincipals, dc = child, dc = klabs, dc = com" "CN = S-1-5-21-1644185942-511557352-3723172775-1107" msDS-PrincipalName We managed to get the PrincipalName property of the user the figure 12_openldap_SSID_to_PrincipalName.JPG Finally, the conclusion we are reaching is that the openldap tool does not work directly between forests, but only on the same tree. We would like to know if this understanding is correct or if this is really a bug in the tool. Well, I tried to detail the situation as much as possible, please help us understand this. Thank you very much for your attention. -- You are receiving this mail because: You are on the CC list for the bug.

1 2

[Bug 8485] [PATCH] Adding support for encrypted server private keys
by openldap-its＠openldap.org 31 Mar '20

31 Mar '20

https://bugs.openldap.org/show_bug.cgi?id=8485 --- Comment #11 from ahnolds(a)gmail.com <ahnolds(a)gmail.com> --- (In reply to Howard Chu from comment #10) > (In reply to Michael Ströder from comment #9) > > I concur that lacking support for encrypted private keys is a real > > deficiency! > > > > In general OpenLDAP should aim to reach more flexibility for the TLS > > configuration, e.g. like Apache httpd. Encrypted private keys for both > > server and client side is one aspect of that. > > We have never needed to add explicit support, since OpenSSL prompted for > a passphrase itself, when needed. > > https://www.openldap.org/lists/openldap-software/200210/msg00718.html It prompts for the passphrase on the controlling terminal, which is only helpful for command-line based applications. For any application run through a GUI/web server/etc, there won't be any way for the user to enter the passphrase as is. And in fact, the call to use the key will hang (forever IIRC) waiting for a passphrase to be typed on the terminal. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 8485] [PATCH] Adding support for encrypted server private keys
by openldap-its＠openldap.org 31 Mar '20

31 Mar '20

https://bugs.openldap.org/show_bug.cgi?id=8485 --- Comment #10 from Howard Chu <hyc(a)symas.com> --- (In reply to Michael Ströder from comment #9) > I concur that lacking support for encrypted private keys is a real > deficiency! > > In general OpenLDAP should aim to reach more flexibility for the TLS > configuration, e.g. like Apache httpd. Encrypted private keys for both > server and client side is one aspect of that. We have never needed to add explicit support, since OpenSSL prompted for a passphrase itself, when needed. https://www.openldap.org/lists/openldap-software/200210/msg00718.html -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 8485] [PATCH] Adding support for encrypted server private keys
by openldap-its＠openldap.org 31 Mar '20

31 Mar '20

https://bugs.openldap.org/show_bug.cgi?id=8485 Ryan Tandy <ryan(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.openldap.org/s | |how_bug.cgi?id=7221 -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 7221] Support private keys in PKCS #8 in slapd when linked with gnutls
by openldap-its＠openldap.org 31 Mar '20

31 Mar '20

https://bugs.openldap.org/show_bug.cgi?id=7221 Ryan Tandy <ryan(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.openldap.org/s | |how_bug.cgi?id=8485 -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 8446] Various bug fixes for the async-meta backend
by openldap-its＠openldap.org 31 Mar '20

31 Mar '20

https://bugs.openldap.org/show_bug.cgi?id=8446 Ondřej Kuzník <ondra(a)mistotebe.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED See Also| |https://bugs.openldap.org/s | |how_bug.cgi?id=8734 -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 8734] Fixes for multiple back-asyncmeta issues
by openldap-its＠openldap.org 31 Mar '20

31 Mar '20

https://bugs.openldap.org/show_bug.cgi?id=8734 Ondřej Kuzník <ondra(a)mistotebe.net> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.openldap.org/s | |how_bug.cgi?id=8446 -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 8446] Various bug fixes for the async-meta backend
by openldap-its＠openldap.org 31 Mar '20

31 Mar '20

https://bugs.openldap.org/show_bug.cgi?id=8446 Ondřej Kuzník <ondra(a)mistotebe.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED -- You are receiving this mail because: You are on the CC list for the bug.

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs March 2020