openldap-bugs

openldap-bugs@openldap.org

1 participants
20969 discussions

[Bug 8511] Rename "mirrormode" to "multimaster", deprecate "mirrormode" parameter
by openldap-its＠openldap.org 01 Apr '20

01 Apr '20

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

1 0

[Bug 8511] Rename "mirrormode" to "multimaster", deprecate "mirrormode" parameter
by openldap-its＠openldap.org 01 Apr '20

01 Apr '20

https://bugs.openldap.org/show_bug.cgi?id=8511 --- Comment #7 from Quanah Gibson-Mount <quanah(a)openldap.org> --- https://git.openldap.org/openldap/openldap/-/merge_requests/18 -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 8511] Rename "mirrormode" to "multimaster", deprecate "mirrormode" parameter
by openldap-its＠openldap.org 01 Apr '20

01 Apr '20

https://bugs.openldap.org/show_bug.cgi?id=8511 --- Comment #6 from Quanah Gibson-Mount <quanah(a)openldap.org> --- (In reply to Ondřej Kuzník from comment #5) > Can't see the patch anywhere, could you create a merge request for this? Yeah, I need to rebase it. ;) -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[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 7706] Update lastbind behavior to allow specific attribute restrictions
by openldap-its＠openldap.org 01 Apr '20

01 Apr '20

https://bugs.openldap.org/show_bug.cgi?id=7706 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|RFE: contrib/slapo-lastbind |Update lastbind behavior to |extension |allow specific attribute | |restrictions -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 9003] Update slapd-ldap(5) idassert-authzfrom for policy difference
by openldap-its＠openldap.org 01 Apr '20

01 Apr '20

https://bugs.openldap.org/show_bug.cgi?id=9003 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|IN_PROGRESS |RESOLVED Resolution|--- |TEST Keywords|has_patch, IPR_OK, | |OL_2_5_REQ, | |openldap-scratch | --- Comment #5 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Commits: • a5b8a41c by Quanah Gibson-Mount at 2020-04-01T19:40:27+00:00 ITS#9003 Note that with slapd-ldap, the special character "*" actually allows anonymous rather than denies, as is the case with authz-policy -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 8628] man pages & Makefile updates for contrib
by openldap-its＠openldap.org 01 Apr '20

01 Apr '20

https://bugs.openldap.org/show_bug.cgi?id=8628 Ondřej Kuzník <ondra(a)mistotebe.net> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.openldap.org/s | |how_bug.cgi?id=8205 --- Comment #16 from Ondřej Kuzník <ondra(a)mistotebe.net> --- Everything except attachment 671 is already applied as part of https://bugs.openldap.org/show_bug.cgi?id=8205 -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 8205] [PATCH] man pages in contrib
by openldap-its＠openldap.org 01 Apr '20

01 Apr '20

https://bugs.openldap.org/show_bug.cgi?id=8205 Ondřej Kuzník <ondra(a)mistotebe.net> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.openldap.org/s | |how_bug.cgi?id=8628 -- 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 #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

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