openldap-bugs

openldap-bugs@openldap.org

1 participants
20959 discussions

(ITS#8571) Added a test for pcache + ldap backen with proxyauthz
by elecharny＠symas.com 18 Jan '17

18 Jan '17

Full_Name: Emmanuel L.charny Version: 2.4.45 OS: N/A URL: ftp://ftp.openldap.org/incoming/elecharny-20170118.patch Submission from: (NULL) (86.246.56.212) This patch adds a unit test for a server configured with proxycache and ldap backend, redirecting all the requests to a remote master server, which does not accept anonymous bind). The proxycache server caches searches and binds. The attached file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Symas. Symas has not assigned rights and/or interest in this work to any party. I, Emmanuel Lecharny, am authorized by Symas, my employer, to release this work under the following terms. Symas hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

Re: (ITS#8565) Clarification of the slapo-ppolicy manpage
by quanah＠symas.com 18 Jan '17

18 Jan '17

--On Wednesday, January 11, 2017 4:44 PM +0000 matthieu.cerda(a)nbs-system.com wrote: > Full_Name: Matthieu Cerda > Version: 2.4.40 > OS: Debian jessie > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (194.213.124.6) > > > Hello ! > > As per > http://www.openldap.org/lists/openldap-technical/201701/msg00017.html I > would like to submit a small improvement to the slapo-ppolicy manpage to > clarify rootdn presence / absence implications in a ppolicy enabled setup. > > Here is the patch (I thing it's short enough not to justify a separate > upload): Thanks! We went with something slightly different, but the rootdn requirement should be absolutely clear now. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8544) manpage fixes
by quanah＠symas.com 18 Jan '17

18 Jan '17

--On Tuesday, December 13, 2016 9:10 PM +0000 sca+openldap(a)andreasschulze.de wrote: > Full_Name: Andreas Schulze > Version: git > OS: linux > URL: ftp://ftp.openldap.org/incoming/andreas-schulze-161213.patch > Submission from: (NULL) (2001:a60:f0b4:e502::152) > > > I uploaded a patch to polish some manpages. > All changes are suggested by debian lintian > - phrase "allows one to" instead of "allows to" > - some occurences of -foo have to be written as \-foo in a manpage Thanks for the report, this has been applied with one minor change. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8568) slapd SASL EXTERNAL bind getprop SSF bug; can provoke SEGFAULT
by william.b.clay＠acm.org 18 Jan '17

18 Jan '17

> So you're using TLS client cert and SASL/EXTERNAL to a hostname (also in ther > server cert) but where the IP address of the hostname is directly routed through > 127.0.0.1? The slapd log of my same-host tests confirms they in fact used the IPv4 loopback address, 127.0.0.1, even though the bind URI specified the FQDN. > Not sure but the difference is the client IP address. If the client can reach > slapd through 127.0.0.1 the client's IP address is also 127.0.0.1 which could > make a difference in the SASL client handling. Anyone said hostname > canonicalization? Does setting sasl-host <fqdn> make a difference? The ~/.ldaprc used by the client in these tests contained "TLS_REQCERT none", so a mismatch between the server's FQDN and the peer address actually used would not have been detected. Another difference would be "ping-pong" memory allocation between client and server. Even though different processes, they may allocate from the same pool. With the client running on a different host in other tests, slapd would not be competing with other processes in a predictable, repeatable fashion (slapd SEGFAULTs were 100% repeatable for specific sequences of EXTERNAL binds, but only with client and server on the same host).

1 0

Re: (ITS#6104) race condition with cancel operation
by michaelgarofalo404＠yahoo.com 18 Jan '17

18 Jan '17

1 0

Re: (ITS#8560) Proxy Authorization is mentioned as a SASL mech
by michael＠stroeder.com 17 Jan '17

17 Jan '17

rick(a)openfortress.nl wrote: > This is in fact what I was looking for; whether OpenLDAP supports this > per-operation Proxy Authz Control. So you can try yourself. The rootdn can always do this. The help of ldapsearch tool says: -e [!]<ext>[=<extparam>] general extensions (! indicates criticality) [..] [!]authzid=<authzid> (RFC 4370; "dn:<dn>" or "u:<user>") Ciao, Michael.

1 0

Re: (ITS#8560) Proxy Authorization is mentioned as a SASL mech
by rick＠openfortress.nl 17 Jan '17

17 Jan '17

Hi Quanah, > Thanks for the report. However, the EXTERNAL mechanism is in fact a > SASL mechanism, just implemented directly in OpenLDAP (vs other SASL > mechanisms that OpenLDAP supports via Cyrus-SASL). The location in > the admin guide is correct. Yes, thanks, Howard also pointed that out, and I learnt. > If you read RFC 4370, Section 1 clearly notes that it is a part of > SASL: > > "The Lightweight Directory Access > Protocol [LDAPV3] supports the use of the Simple Authentication and > Security Layer [SASL] for authentication and for supplying an > authorization identity distinct from the authentication identity, > where the authorization identity applies to the whole LDAP session." Ehm, it doesn't actually state that Proxied Authz is part of SASL. It just continues to state that it is on a per-operation basis, and to me it reads like an independent mechanism, at least as far as the protocol is concerned. Although it can be easily imagined that it were to share (lots of) code with SASL EXTERNAL of course, but that would be an implementation choice. Or am I still not reading it correctly? This is in fact what I was looking for; whether OpenLDAP supports this per-operation Proxy Authz Control. Aside from the above being properly located, I am still missing a remark about it in the Manual. Thanks, -Rick

1 0

Re: (ITS#8560) Proxy Authorization is mentioned as a SASL mech
by quanah＠symas.com 17 Jan '17

17 Jan '17

--On Friday, January 06, 2017 7:17 PM +0000 rick(a)openfortress.nl wrote: > Full_Name: Rick van Rein > Version: 2.4 > OS: N/A > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2001:980:93a5:1:98ff:3cc8:e968:ded8) > > > Hello, > > I found a nit in the OpenLDAP administrator's guide at > http://www.openldap.org/doc/admin24/guide.html#SASL%20Proxy%20Authorizati > on > > It mentions Proxy Authorization as a facility of SASL, something I never > heard of. It is defined specifically for LDAP in RFC 4370. So the > chapter title, and perhaps its ordering underneath SASL, are not perfect. Hi Rick, Thanks for the report. However, the EXTERNAL mechanism is in fact a SASL mechanism, just implemented directly in OpenLDAP (vs other SASL mechanisms that OpenLDAP supports via Cyrus-SASL). The location in the admin guide is correct. If you read RFC 4370, Section 1 clearly notes that it is a part of SASL: "The Lightweight Directory Access Protocol [LDAPV3] supports the use of the Simple Authentication and Security Layer [SASL] for authentication and for supplying an authorization identity distinct from the authentication identity, where the authorization identity applies to the whole LDAP session." Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8563) Documentation inconsistency for syncrepl for mdb
by quanah＠symas.com 17 Jan '17

17 Jan '17

--On Saturday, January 07, 2017 8:13 PM +0000 dpa-openldap(a)aegee.org wrote: > Full_Name: &#1044;&#1080;&#1083;&#1103;&#1085; > &#1055;&#1072;&#1083;&#1072;&#1091;&#1079;&#1 > 086;&#1074; Version: 2.4.44 > OS: any > URL: > Submission from: (NULL) (141.2.134.77) > > > The manual states in section 5.2.5.8 olcSyncrepl, second last paragraph: > "The syncrepl replication mechanism is supported by the bdb and hdb > backends". > > This text above is repeated in section 6.2.3.7 syncrepl. > > But in section 18.1.1.2. Syncrepl Details, fourth paragraph, is written > 'The syncrepl engine, which is a consumer-side replication engine, can > work with any backends. The LDAP Sync provider can be configured as an > overlay on any backend, but works best with the back-bdb back-hdb, or > back-mdb backends.' > > Can syncrepl work with any backend and does it work with bdb equally good > as with mdb? Fixed to mention back-mdb/mdb where appropriate. At the time the documentation was written, back-mdb didn't exist. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8562) Typos in the documentation
by quanah＠symas.com 17 Jan '17

17 Jan '17

--On Saturday, January 07, 2017 7:24 PM +0000 dpa-openldap(a)aegee.org wrote: > Full_Name: &#1044;&#1080;&#1083;&#1103;&#1085; > &#1055;&#1072;&#1083;&#1072;&#1091;&#1079;&#1 > 086;&#1074; Version: 2.4.44 > OS: any > URL: > Submission from: (NULL) (141.2.134.77) > > > In the manual, > - section 8.2.5 Access Control Examples, 2nd paragraph replace "allows > anonymous to authentication against these entries" with "authenticate"; > - section 13.2.4 Attibute Type Specification, 4th code snippet, replace > "DESC 'common name(s) assciated with the object" with "associated"; > - section8.8.1.1 LDAP Sync Replication, last paragraph, replace "is > defined by a general search criteria consisting of base and scope': > remove the 'a' in front of criteria. > - section 20 Monitoring, 3rd paragraph "This information can be access > with ldapsearch", substitute with "accessed". Fixed, thanks, outside of the "a general search criteria consisting of base and scope". That seems correct to me. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

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