openldap-bugs January 2011

openldap-bugs@openldap.org

36 participants
177 discussions

Re: (ITS#6804) 'self' access modifier only works for first entry
by hyc＠symas.com 26 Jan '11

26 Jan '11

djpohly(a)gmail.com wrote: > Full_Name: Devin J. Pohly > Version: 2.4.23 > OS: Linux > URL: http://openldap.pastebin.com/gvswpxLX > Submission from: (NULL) (98.235.33.55) Thanks for the detailed report. This is now fixed in HEAD. > Description: > I have set up an LDAP directory which contains users and flat groups > (groupOfNames/member style). I want to use the access controls to only allow > users to see their own groups and membership, so I defined the following > controls: > > access to dn.onelevel="ou=group,o=org" attrs=entry > by dnattr=member read > access to dn.onelevel="ou=group,o=org" attrs=member > by dnattr=member selfread > > Steps to reproduce: > 1. Start a new instance of OpenLDAP with the slapd.conf file provided at > <http://openldap.pastebin.com/gvswpxLX> and an empty database. > 2. Get grouptest.ldif from<http://openldap.pastebin.com/X1DUyGmf> and add it to > the directory: > ldapadd -x -H $LDAPURI -D uid=admin,o=org -w admin -f grouptest.ldif > This creates two users, foo and bar, and two groups, g1 and g2. Each user is in > both groups. > 3. Compare the outputs of: > ldapsearch -x -H $LDAPURI -D uid=foo,ou=user,o=org -w foo -b ou=group,o=org > ldapsearch -x -H $LDAPURI -D uid=bar,ou=user,o=org -w bar -b ou=group,o=org > > Expected results: > Foo's query shows "member: foo" for both g1 and g2. Bar's query shows "member: > bar" for both g1 and g2. > > Actual results: > Foo's query shows "member: foo" for both g1 and g2. Bar's query does not show > any member attributes. > > Note: Changing the order in which the users are listed changes the behavior; > only the first user listed matches 'self'. Changing the 'selfread' privilege to > 'read' behaves correctly: both queries display both users' memberships in the > groups. So the problem lies somewhere in the way the 'self' modifier is > implemented. > -- -- 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#6805
by Kurt＠OpenLDAP.org 26 Jan '11

26 Jan '11

The OP expects somehow for the server to prevent the client from = exposing information when the server has no control over what the client = sends. This simply is not possible and hence should not be expected. Even if the server were configured only with a ldaps:// listener, = clients would not be precluded from sending a password to the server in = the clear. A client could be told to connect to that listener and send = a LDAP Simple Bind with password without ever attempting to start TLS. = Sure, the server will error, but the password is exposed none the less. As you indicate, the same issue exist in more robust clients as well. = It's quite hard to provide client configurability and prevention from = misconfiguration which lead to security issues concurrently. How is the = client software to know that StartTLS or ldaps:// was wanted with it = wasn't so configured? The best a robust client could do here is warn = the user of security concerns that arise from their configuration = choices. I would have no objection to adding such robustness to OpenLDAP command = line tools so long as such warnings were off by default. Kicking out = warnings as the default would likely break a lot of scripts which use = OpenLDAP command line tools. -- Kurt=

1 0

Re: (ITS#5472) ldap_get_values() should handle paged results from LDAP/AD
by Kurt＠OpenLDAP.org 26 Jan '11

26 Jan '11

On Jan 26, 2011, at 11:23 AM, masarati(a)aero.polimi.it wrote: >>=20 >> On Jan 26, 2011, at 9:15 AM, masarati(a)aero.polimi.it wrote: >>=20 >>> The complexity of handling this nonsense in libldap seems not worth = the >>> effort; >>=20 >> Ando, you are too kind to refer this extension as 'nonsense'. It's = worse >> than nonsense, it's crap. >>=20 >> The spec you pointed at says: "LDAP servers often place limits on the >> maximum number of attribute values that can be retrieved in a single >> query." >=20 > I'd reword that as "One specific LDAP server places limits on the = maximum > number of attribute values that can be retrieved in a single query." >=20 >> The spec fails to say why would a server want to do that. I >> cannot think of any good reason to do precisely that. While I can >> understand a desire to place limits on what clients can retrieve, I = don't >> see why one would distinguish between a single query and a set of = queries. >> I can also see it desirable to allow a client to page through results >> (but that's a different matter, this is about forcing paging onto >> clients). >>=20 >> It is incredibly stupid to require clients to use multiple operations = to >> obtain information for which the protocol allowed to be fetched in a >> single operation, and this is why I refer to this as "crap". >=20 > :) >=20 >> A major problem with paging, whether server-forced or at = client-option, is >> result set coherency due to changes to the DIT between when various = page >> operations are obtain. This can lead to problems such a member of a = group >> not appearing in the results. While one might argue client might be = able >> to reasonable deal with coherency issues, most client developers = won't. >> This will lead to a range of security issues creeping into directory >> applications. >>=20 >> So while I don't generally oppose introduction of paging extensions = at the >> client option, I think the specifications should warn that the = clients >> using them need to be designed to handle data coherency issues. = However, >> most designers of such extensions seem to have put no thought into = this >> issue at all. >=20 > Well, I don't see paged results as a way to introduce more = inconsistency > than a regular search operation, since nowhere in the specs I see that = the > collection of the entries returned by a search are consistent with the > entries matching the search request at a specific time (e.g. when the > operation was initiated or so). As a consequence, clients need be = aware > of the fact that search results can be inherently inconsistent, paging = or > not. As LDAP is defined as an access protocol to an X.500 directory, it = inherits some data consistency expectations. In generally expected that = entry-level access have ACID properties. That is, each successful = modify operation creates a new DIT state and a read operation returns = information consistent with a particular state. That is, say the DIT = has state X and there is modify operation that produces state Y and a = concurrent issued read operation (and no other operations), the read = operation will return either state X or state Y depending on whether it = is processed before or after the modify operation. The read ought not = provide some intermediate state. A search operation acts upon a collection of entries, there is a = possibility of inconsistencies between different entries (but not within = them), especially in distributed DITs. However, as we're talking about values of an attribute of a particular = entry, this is a non-issue in this discussion.

1 0

ITS#6805
by masarati＠aero.polimi.it 26 Jan '11

26 Jan '11

I'd note that sending cleartext credentials is just wrong regardless of the ssf the server requires. OpenLDAP's ldapsearch assumes users know what they are doing. Actually, this client is mainly intended as a tool that allows to perform operations with as many parameter combinations as needed to test the functionalities of slapd. What you recommend would probably be appropriate for a "real life" client implementation. Moreover, the only way to test whether the security factor requested by the server is in place would require the client to attempt a simple bind with intentionally invalid credentials; considering slapd's possibility to configure security per-database, one would need to either use the "right" DN (thus exposing it), or a fake DN that for sure is within the same naming context, and incorrect credentials. I believe this amount of wisdom is beyond any "real life" client implementation. Of course I would not object to any patch for ldapsearch (actually, for all clients) that solves this problem in a general manner without requiring any user intervention. p.

1 0

(ITS#6805) ldapsearch can expose cleartext password needlessly
by leblanc＠math.toronto.edu 26 Jan '11

26 Jan '11

Full_Name: Emile LeBlanc Version: openldap-clients-2.3.43-12.el5_5.3.i386 OS: Red Hat Enterprise Linux 5.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.100.68.202) I am running the latest version of ldapsearch (that comes with Red Hat Enterprise Linux 5.6) on my machine. If I run: ldapsearch -Z -W -LLL -D "uid=guest,ou=Unit,dc=math,dc=toronto,dc=edu" -H ldap://test.math.toronto.edu -x -b "dc=math,dc=toronto,dc=edu" "(uid=guest)" then the result is as I expect (after I type the passwd to the "Enter LDAP Password:" prompt). However if I remove the "-Z" flag and run: ldapsearch -W -LLL -D "uid=guest,ou=Unit,dc=math,dc=toronto,dc=edu" -H ldap://test.math.toronto.edu -x -b "dc=math,dc=toronto,dc=edu" "(uid=guest)" then, after typing the password I see: ldap_bind: Confidentiality required (13) additional info: confidentiality required This result was also expected since the ldap server has: security ssf=256 in the slapd.conf file. What was unexpected was that the password was sent in cleartext in the second "ldapsearch" command (I verified this with "wireshark", a network packet analyzer). It is true that I should use the "-Z" flag if I want encryption but I think that a simple error on the client end should not expose a password when the initial connection to a secured server could have been tried without transmitting the password to see if additional security was needed. Perhaps there is some good reason for the current behavior, but I wanted to make sure that people realized what was happening. Perhaps the performance hit my suggestion would entail is not worth it for other users. Thank you.

1 0

Re: (ITS#5472) ldap_get_values() should handle paged results from LDAP/AD
by masarati＠aero.polimi.it 26 Jan '11

26 Jan '11

> > On Jan 26, 2011, at 9:15 AM, masarati(a)aero.polimi.it wrote: > >> The complexity of handling this nonsense in libldap seems not worth the >> effort; > > Ando, you are too kind to refer this extension as 'nonsense'. It's worse > than nonsense, it's crap. > > The spec you pointed at says: "LDAP servers often place limits on the > maximum number of attribute values that can be retrieved in a single > query." I'd reword that as "One specific LDAP server places limits on the maximum number of attribute values that can be retrieved in a single query." > The spec fails to say why would a server want to do that. I > cannot think of any good reason to do precisely that. While I can > understand a desire to place limits on what clients can retrieve, I don't > see why one would distinguish between a single query and a set of queries. > I can also see it desirable to allow a client to page through results > (but that's a different matter, this is about forcing paging onto > clients). > > It is incredibly stupid to require clients to use multiple operations to > obtain information for which the protocol allowed to be fetched in a > single operation, and this is why I refer to this as "crap". :) > A major problem with paging, whether server-forced or at client-option, is > result set coherency due to changes to the DIT between when various page > operations are obtain. This can lead to problems such a member of a group > not appearing in the results. While one might argue client might be able > to reasonable deal with coherency issues, most client developers won't. > This will lead to a range of security issues creeping into directory > applications. > > So while I don't generally oppose introduction of paging extensions at the > client option, I think the specifications should warn that the clients > using them need to be designed to handle data coherency issues. However, > most designers of such extensions seem to have put no thought into this > issue at all. Well, I don't see paged results as a way to introduce more inconsistency than a regular search operation, since nowhere in the specs I see that the collection of the entries returned by a search are consistent with the entries matching the search request at a specific time (e.g. when the operation was initiated or so). As a consequence, clients need be aware of the fact that search results can be inherently inconsistent, paging or not. > I do generally oppose introduction of non-truly optional extensions in > LDAP (and in other application protocols). One would think that a > requirement that extensions to a protocol be truely optional would go > without saying, but in IETF we actually found it necessary to explicitly > state this in the BCP governing LDAP extensions. > > That BCP will effectively stop non-truly optional extension proposal as > this from gaining Standard Track status in the IETF. > >> I think we might consider working this around in proxy backends >> (much like we did for unsolicited paged results response in back-meta, >> ITS#6664, which could be added to back-ldap as well). > > I would think it easier to reconfigure AD not to have the limits which > cause this sort of paging. Of course. The whole discussion about this issue (and others) and often the thrust that pushes the development of many features in the proxy backends (and other features, like slapo-rwm, slapo-translucent and more) is the practical impossibility to affect the configuration of one or more remote servers. p.

1 0

Re: (ITS#5472) ldap_get_values() should handle paged results from LDAP/AD
by sgallagh＠redhat.com 26 Jan '11

26 Jan '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/26/2011 12:15 PM, masarati(a)aero.polimi.it wrote: > > The complexity of handling this nonsense in libldap seems not worth the > effort; I think we might consider working this around in proxy backends > (much like we did for unsolicited paged results response in back-meta, > ITS#6664, which could be added to back-ldap as well). > > I don't think implementing something that requires a theoretically > unbounded number of nested search requests for each attribute value that > contains a range in each SearchResultEntry message makes sense. I didn't suggest that it should be enabled by default. I was looking for an option that could be set if a particular client needs it. > The parallel with referrals is not appropriate, since referrals are part > of LDAP specification; also, please note that automatic referral chasing > is strongly discouraged unless the transport layer is protected (Section 6 > of RFC 4511). Right, I really only meant in the broad sense of "You can enable this option if you really need it, knowing that there are risks and the potential for going through multiple additional requests". I just meant there was precedent for adding features that required extra trips to the server. I also fully agree that the range extension is a crime against decency, but unfortunately it's backed by the 800-pound gorilla that we can't just ignore. I think if we're stuck with it, it makes sense to put the code to deal with it in common OpenLDAP library code instead of forcing every consumer to rewrite it. Because at the end of the day, pretty much every LDAP client is going to need to be able to talk to Active Directory at some point. - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk1Abw8ACgkQeiVVYja6o6MsjwCdFtTmbHk0yj16JT6Fz/ffU2QF bcQAmwaV/aWcJL4dk3QFtYgD11OvZ1QV =69z3 -----END PGP SIGNATURE-----

1 0

Re: (ITS#5472) ldap_get_values() should handle paged results from LDAP/AD
by Kurt＠OpenLDAP.org 26 Jan '11

26 Jan '11

On Jan 26, 2011, at 9:15 AM, masarati(a)aero.polimi.it wrote: > The complexity of handling this nonsense in libldap seems not worth = the > effort; Ando, you are too kind to refer this extension as 'nonsense'. It's = worse than nonsense, it's crap. The spec you pointed at says: "LDAP servers often place limits on the = maximum number of attribute values that can be retrieved in a single = query." The spec fails to say why would a server want to do that. I = cannot think of any good reason to do precisely that. While I can = understand a desire to place limits on what clients can retrieve, I = don't see why one would distinguish between a single query and a set of = queries. I can also see it desirable to allow a client to page through = results (but that's a different matter, this is about forcing paging = onto clients). It is incredibly stupid to require clients to use multiple operations to = obtain information for which the protocol allowed to be fetched in a = single operation, and this is why I refer to this as "crap". A major problem with paging, whether server-forced or at client-option, = is result set coherency due to changes to the DIT between when various = page operations are obtain. This can lead to problems such a member of = a group not appearing in the results. While one might argue client = might be able to reasonable deal with coherency issues, most client = developers won't. This will lead to a range of security issues creeping = into directory applications. So while I don't generally oppose introduction of paging extensions at = the client option, I think the specifications should warn that the = clients using them need to be designed to handle data coherency issues. = However, most designers of such extensions seem to have put no thought = into this issue at all. I do generally oppose introduction of non-truly optional extensions in = LDAP (and in other application protocols). One would think that a = requirement that extensions to a protocol be truely optional would go = without saying, but in IETF we actually found it necessary to explicitly = state this in the BCP governing LDAP extensions. That BCP will effectively stop non-truly optional extension proposal as = this from gaining Standard Track status in the IETF. > I think we might consider working this around in proxy backends > (much like we did for unsolicited paged results response in back-meta, > ITS#6664, which could be added to back-ldap as well). I would think it easier to reconfigure AD not to have the limits which = cause this sort of paging. > I don't think implementing something that requires a theoretically > unbounded number of nested search requests for each attribute value = that > contains a range in each SearchResultEntry message makes sense. >=20 > The parallel with referrals is not appropriate, since referrals are = part > of LDAP specification; also, please note that automatic referral = chasing > is strongly discouraged unless the transport layer is protected = (Section 6 > of RFC 4511). >=20 > p.

1 0

ITS#5472
by masarati＠aero.polimi.it 26 Jan '11

26 Jan '11

For future reference, if needed: <http://msdn.microsoft.com/en-us/library/aa367017(v=vs.85).aspx>

1 0

Re: (ITS#5472) ldap_get_values() should handle paged results from LDAP/AD
by masarati＠aero.polimi.it 26 Jan '11

26 Jan '11

> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I'd like to reopen the discussion on this issue. We're hitting this same > problem with the SSSD when dealing with ActiveDirectory. It really > doesn't make sense to me that every consumer of the OpenLDAP libraries > should be required to reimplement this (admittedly incorrect) extension > to ActiveDirectory. > > As Petter suggested in his comment from April 21, 2008, ActiveDirectory > provides a server control to identify that the feature is in play. > > I feel that it would be beneficial to OpenLDAP's library consumers if > they handled range lookups automatically and internally, similar to the > way that referrals are chased. > > Consumers of the OpenLDAP API should be able to reliably assume that if > they ask for the set of values for an attribute of a completed request, > that they will get back all of the values. > > Please reconsider adding this support into OpenLDAP. The complexity of handling this nonsense in libldap seems not worth the effort; I think we might consider working this around in proxy backends (much like we did for unsolicited paged results response in back-meta, ITS#6664, which could be added to back-ldap as well). I don't think implementing something that requires a theoretically unbounded number of nested search requests for each attribute value that contains a range in each SearchResultEntry message makes sense. The parallel with referrals is not appropriate, since referrals are part of LDAP specification; also, please note that automatic referral chasing is strongly discouraged unless the transport layer is protected (Section 6 of RFC 4511). p.

1 0

← Newer
1
2
3
4
5
6
7
8
...
18
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs January 2011