openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

Re: (ITS#6456) Feature Request
by masarati＠aero.polimi.it 09 Apr '10

09 Apr '10

> Full_Name: J > Version: 2.4.20 > OS: Debian-Lenny/amd64 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (68.15.14.98) > > > Greetings, > > Having found out this doesn't already exist as another parameter or > configuration method, I am hereby submitting a request for a particular > feature. > > When performing idassert-bind operations, such as with back_ldap, it would > be > great if an option could be added which would allow specific matched > client DNs > to be matched and asserted as usual (e.g: the anonymous user asserting to > a > backend "proxyauthenticator" account) .... while other clients (flagged > somehow) > would pass-through as themselves. > > Example (as I might do it for my purposes): > > idassert-bind > bindmethod="simple" > binddn="uid=proxyauthenticator,ou=users,dc=example,dc=com" > credentials="password_string" > starttls="yes" > tls_reqcert="never" > mode="none" > > # anonymous clients will assert as "proxyauthenticator", since the backend > may > not allow anonymous binds. > idassert-authzFrom "dn.exact:" > > # this guy will pass through as himself to the backend, as-is. > idassert-passThrough "dn.exact:uid=admin,ou=users,dc=example,dc=com" > > This would be really helpful, not sure if its difficult to implement ... This is now implemented in back-ldap (idassert-passthru, olcDbIDAssertPassThru, undocumented yet). Basically, identities matching rules formally identical to those of idassert-authzFrom do not undergo identity assertion. This rule is checked before idassert-authzFrom, so in case an identity matches both, passthru wins. Please test and report. p.

1 0

Re: (ITS#6194) Patch - Enhancement - provide LDIF support as libldif
by masarati＠aero.polimi.it 09 Apr '10

09 Apr '10

> Full_Name: Rich Megginson > Version: CVS HEAD (2.4.21+) > OS: Fedora > URL: > ftp://ftp.openldap.org/incoming/openldap-2.4.21-libldif-and-new-ldif-api-20… > > This patch allows liblutil to provide the LDIF reading and writing > functions as > public APIs in a libldif, and exposes ldif.h to the public API. This > patch also creates > a new LDAP API for parsing raw LDIF records into higher level LDAP > structures > such as LDAPMod and LDAPControl - ldap_parse_ldif_record() - and changes > ldapmodify.c to use the new API. > > This patch file is derived from OpenLDAP Software. All of the > modifications to OpenLDAP Software represented in the following > patch(es) were developed by Red Hat, Inc.. Red Hat, Inc. has not > assigned rights and/or interest in this work to any party. I, Richard > Megginson am authorized by Red Hat, Inc., my employer, to release this > work under the following terms. > > Red Hat, Inc. 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. Kurt, if you give IPR clearance I can start (evaluating and) integrating this. p.

1 0

Re: (ITS#6432) PATCH: MozNSS crypto (tls_m.c) - support InitContext, improved PEM support
by rmeggins＠redhat.com 09 Apr '10

09 Apr '10

Any update on this?

1 0

Re: (ITS#6194) Patch - Enhancement - provide LDIF support as libldif
by rmeggins＠redhat.com 09 Apr '10

09 Apr '10

Full_Name: Rich Megginson Version: CVS HEAD (2.4.21+) OS: Fedora URL: ftp://ftp.openldap.org/incoming/openldap-2.4.21-libldif-and-new-ldif-api-20… This patch allows liblutil to provide the LDIF reading and writing functions as public APIs in a libldif, and exposes ldif.h to the public API. This patch also creates a new LDAP API for parsing raw LDIF records into higher level LDAP structures such as LDAPMod and LDAPControl - ldap_parse_ldif_record() - and changes ldapmodify.c to use the new API. This patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Red Hat, Inc.. Red Hat, Inc. has not assigned rights and/or interest in this work to any party. I, Richard Megginson am authorized by Red Hat, Inc., my employer, to release this work under the following terms. Red Hat, Inc. 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#6510) GSSAPI rebind proc will cause mutex deadlock
by hyc＠symas.com 09 Apr '10

09 Apr '10

Kurt(a)OpenLDAP.org wrote: > On Apr 8, 2010, at 8:08 PM, Howard Chu wrote: > >> Kurt(a)OpenLDAP.org wrote: >>> On Apr 8, 2010, at 3:58 PM, hyc(a)symas.com wrote: >>> =20 >>>> Sounds like your servers are mis-configured, it is not legal to send = > a=3D20=3D >>> =20 >>>> referral in response to a Bind request. >>> =20 >>> I note that the technical specification doesn't actually preclude = > return =3D >>> of a referral in response to a Bind request. However, in practice, = > such =3D >>> return is quite problematic due to ambiguous semantics and security =3D= > >>> considerations. >> =20 >> Right. I can't find the discussion we had about this back in 2004, but = > certainly we've already hashed this out in great detail before. >> =20 >> The fact is that acting on a referral simply means performing a Bind = > against some other server. >> It does nothing for the authentication state of the session on the = > original server. > > Right, by returning a referral, regardless of how far the client got in = > authentication process (including completion of all challenges), the = > client is now anonymous at the original server. > > And there's a security concern, the referral information is not = > protected by the underlying authentication mechanism. It is actually = > quite possible that this be used by an attacker to cause the client to = > try authentication multiple times, possibly with chosen plaintext. > > I recommend that the library never chase bind referrals. Agreed. Patched in HEAD. > (I tend to = > think of rebind as a misfeature. Robust clients really should be using = > the async API and carefully managing security contexts and chasing.) -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6511) syncrepl unreliable, stops when master is temporary unreachable
by quanah＠zimbra.com 09 Apr '10

09 Apr '10

--On Friday, April 09, 2010 10:23 AM +0000 wilco(a)baanhofman.nl wrote: > Full_Name: Wilco Baan Hofman > Version: 2.4.11 > OS: Debian > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (86.82.223.18) Please don't file bug reports against ancient releases. The current stable release is OpenLDAP 2.4.21. If you can reproduce your issue using that release, then file an ITS. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6511) syncrepl unreliable, stops when master is temporary unreachable
by masarati＠aero.polimi.it 09 Apr '10

09 Apr '10

> Behaviour: > Syncrepl stops working when the master server is temporarily unreachable > or > restarted. > > Expected behaviour: > Retrying to connect indefinatly, once every 10 to 30 seconds. > > Result: > This means we have to restart slapd every time there has been a slight > glitch in > the internet connection. I assume you did not read this <http://www.openldap.org/faq/data/cache/56.html> before filing the bug report. In any case, even assuming the behavior you report is caused by a bug (you are not providing any information that is vaguely useful to this extent), there has been substantial development since 2.4.11, specifically in the area of syncrepl. Unless the issue reproduces in the latest release, there is no point in even starting tracking it down. p.

1 0

(ITS#6511) syncrepl unreliable, stops when master is temporary unreachable
by wilco＠baanhofman.nl 09 Apr '10

09 Apr '10

Full_Name: Wilco Baan Hofman Version: 2.4.11 OS: Debian URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (86.82.223.18) Hi, Behaviour: Syncrepl stops working when the master server is temporarily unreachable or restarted. Expected behaviour: Retrying to connect indefinatly, once every 10 to 30 seconds. Result: This means we have to restart slapd every time there has been a slight glitch in the internet connection. Regards, Wilco Baan Hofman

1 0

Re: (ITS#6510) GSSAPI rebind proc will cause mutex deadlock
by Kurt＠OpenLDAP.org 08 Apr '10

08 Apr '10

On Apr 8, 2010, at 8:08 PM, Howard Chu wrote: > Kurt(a)OpenLDAP.org wrote: >> On Apr 8, 2010, at 3:58 PM, hyc(a)symas.com wrote: >>=20 >>> Sounds like your servers are mis-configured, it is not legal to send = a=3D20=3D >>=20 >>> referral in response to a Bind request. >>=20 >> I note that the technical specification doesn't actually preclude = return =3D >> of a referral in response to a Bind request. However, in practice, = such =3D >> return is quite problematic due to ambiguous semantics and security =3D= >> considerations. >=20 > Right. I can't find the discussion we had about this back in 2004, but = certainly we've already hashed this out in great detail before. >=20 > The fact is that acting on a referral simply means performing a Bind = against some other server. > It does nothing for the authentication state of the session on the = original server. Right, by returning a referral, regardless of how far the client got in = authentication process (including completion of all challenges), the = client is now anonymous at the original server. And there's a security concern, the referral information is not = protected by the underlying authentication mechanism. It is actually = quite possible that this be used by an attacker to cause the client to = try authentication multiple times, possibly with chosen plaintext. I recommend that the library never chase bind referrals. (I tend to = think of rebind as a misfeature. Robust clients really should be using = the async API and carefully managing security contexts and chasing.) -- Kurt=

1 0

Re: (ITS#6510) GSSAPI rebind proc will cause mutex deadlock
by hyc＠symas.com 08 Apr '10

08 Apr '10

Kurt(a)OpenLDAP.org wrote: > On Apr 8, 2010, at 3:58 PM, hyc(a)symas.com wrote: > >> Sounds like your servers are mis-configured, it is not legal to send a=20= > >> referral in response to a Bind request. > > I note that the technical specification doesn't actually preclude return = > of a referral in response to a Bind request. However, in practice, such = > return is quite problematic due to ambiguous semantics and security = > considerations. Right. I can't find the discussion we had about this back in 2004, but certainly we've already hashed this out in great detail before. The fact is that acting on a referral simply means performing a Bind against some other server. It does nothing for the authentication state of the session on the original server. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

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