openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

(ITS#5205) CVS to RSS Web Enhancement
by ghenry＠OpenLDAP.org 28 Oct '07

28 Oct '07

Full_Name: Gavin Henry Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.159.59.85) Submitted by: ghenry Hi, It would be great to have something like: http://www.google.co.uk/search?q=cvs2rss&ie=utf-8&oe=utf-8&aq=t&rls=org.moz… Gavin.

1 0

Re: (ITS#5204) Openldap and undefined symbols
by hyc＠symas.com 27 Oct '07

27 Oct '07

galtgendo(a)o2.pl wrote: > Full_Name: Rafał Mużyło > Version: 2.3.38 > OS: Linux > URL: > Submission from: (NULL) (89.228.37.72) > > > A few months ago I came across a problem that I reported to Gentoo Bugzilla, > however that bug (http://bugs.gentoo.org/show_bug.cgi?id=189817) was closed as > invalid. I don't think that it was, at least not 100%. You got the correct answer in comment #2 on that bug. There is no bug in OpenLDAP here. This ITS will be closed. I note that libldap_r was primarily written for use by slapd and slurpd, and nothing else. The only publically documented LDAP API only uses libldap. If you have any software linking against libldap_r, and it's not working, then you should go file a bug with whatever other software is involved. -- -- Howard Chu Chief Architect, 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#5195) ssf not available during sasl bind
by russell-openldap＠stuart.id.au 26 Oct '07

26 Oct '07

On Fri, 2007-10-26 at 19:59 -0700, Quanah Gibson-Mount wrote: > > ldapsearch -ZZ -U "openldap" -b "dc=pwd,dc=lubemobile,dc=com,dc=au" > > "(uid=it)" ldap_sasl_interactive_bind_s: Confidentiality required (13) > > additional info: SASL confidentiality required > > > > Is that a bug? > > > I suggest reading the part on sasl-secprops in the slapd.conf (5) man page. > It notes that the default is to setting is to block anonymous and plain > SASL binds. I suspect you are right in that is the cause of the problem because a -Y DIGEST-MD5 fixes it. But, as I said, it worked before the security option was added. It worked because DIGEST-MD5 was the default. So why isn't it the default now? Now that you have pointed it out, I guess that the addition of the 'security' option prevented SASL from searching dn="" for the types of authentications supported. > access to userPassword > by users read sasl_ssf=128 break > by users read tls=128 > > I think might do it. You would think that would do it - certainly I did. But you would be wrong. Currently it doesn't, and that is what this ITS is about. The patch I supplied with the initial bug report changes things so it does work.

1 0

Re: (ITS#5195) ssf not available during sasl bind
by quanah＠zimbra.com 26 Oct '07

26 Oct '07

--On Saturday, October 27, 2007 3:00 AM +0000 quanah(a)zimbra.com wrote: > access to userPassword > by users read sasl_ssf=128 break > by users read tls=128 Replace users by self, sorry. Obviously you don't want any user to read it. ;) Although hm, anonymous need access at least for auth, so: access to userPassword by anonymous auth by self read sasl_ssf=128 break by self read tls=128 Note that in the anonymous access case, the user password is never transmitted from the server end, in any case. You could do a similar requirement as above, something like: access to userPassword by anonymous auth sasl_ssf=128 break by anonymous auth tls=128 by self read (At this point, you've forced any user to be encrypted, so no need to duplicate the requirements on the read access). --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5195) ssf not available during sasl bind
by quanah＠zimbra.com 26 Oct '07

26 Oct '07

--On Friday, October 26, 2007 9:47 AM +0000 russell-openldap(a)stuart.id.au wrote: > I have now tried: > > security tls=128 sasl=128 > > It didn't work. All the commands below work without > the 'security' option. This says: Require a TLS section of 128 bit security AND SASL security of 128. > ldapsearch -x -ZZ -D "uid=openldap,dc=auth,dc=lubemobile,dc=com,dc=au" > -w "$(ssu cat /etc/libnss-ldap.secret)" -b > "dc=pwd,dc=lubemobile,dc=com,dc=au" "(uid=it)" ldap_bind: You aren't using SASL here. So of course it fails. > Which, when I think about it may be reasonable. I am > apparently saying I require a sasl ssf of 128, and > obviously I don't have that. This was a surprise > though: Right. > ldapsearch -ZZ -U "openldap" -b "dc=pwd,dc=lubemobile,dc=com,dc=au" > "(uid=it)" ldap_sasl_interactive_bind_s: Confidentiality required (13) > additional info: SASL confidentiality required > > Is that a bug? I suggest reading the part on sasl-secprops in the slapd.conf (5) man page. It notes that the default is to setting is to block anonymous and plain SASL binds. > Anyway, bugs aside, assuming I now have some idea how it > works its useless for my application. I want to insist > that userPassword to be encrypted when sent and received, > be that via CRAM-MD5 or friends or by using TLS, but clear > text is fine for the rest of the information in the ldap > database, and in fact anonymous connections unencrypted > connections are the rule for VPN access. The 'security' > option applies to all connections. access to userPassword by users read sasl_ssf=128 break by users read tls=128 I think might do it. > Anyway, to state the problem as clearly as I can, I can't > see how to do the following combination of things: > > . Allow anonymous access over unencrypted connections > for the bulk of the database. Above acl followed by access to * by * read (or however else limited). > . Allow simple binds, but they must be over encrypted > connections to protect userPassword. See above ACL. > . Allow sasl binds over unencrypted connections, but > the must not use clear text. Read the sasl-secprops setting. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5204) Openldap and undefined symbols
by galtgendo＠o2.pl 26 Oct '07

26 Oct '07

Full_Name: Rafał Mużyło Version: 2.3.38 OS: Linux URL: Submission from: (NULL) (89.228.37.72) A few months ago I came across a problem that I reported to Gentoo Bugzilla, however that bug (http://bugs.gentoo.org/show_bug.cgi?id=189817) was closed as invalid. I don't think that it was, at least not 100%. I'm not really an openldap user, I simply have it installed as a dependency and probably I'm not using it at all. This is simply something that I noticed while I was building wine. During configure, openldap was not detected, although it was installed. I filed it as --as-needed issue, now, however, I no longer think it the case. As the bug mentions, libldap_r.so had undefined symbols from pthread, so standard configure lib check was failing. I thought that it was an as-needed issue, but now I'm not so sure. You have a closed Build/2209 bug (about an unrelated issue). From the first reply I quote: "It ought to be linked with any libraries it depends on and pull them in implicitly.". Shouldn't it be the same for libldap_r.so - meaning shouldn't it be linked with pthread ? After some checking I found that libslapi.so and most of /usr/lib/openldap have undefined symbols, too, but as far as I understand libslapi is internal use only and it's a design issue cause many symbols that libslapi uses are defined later in slapd (yes, I read that Windows note in servers/slapd/Makefile.in).

1 0

Re: (ITS#5203) [LDAP: error code 32 - No Such Object];
by quanah＠zimbra.com 26 Oct '07

26 Oct '07

--On Friday, October 26, 2007 10:53 AM +0000 hiremath47(a)gmail.com wrote: > Full_Name: Siddeshawr > Version: Version 2.8 > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (203.92.60.81) The ITS system is for bug reports, not usage questions. Please use openldap-software(a)openldap.org for questions you have about using OpenLDAP. I will also note that "2.8" is not a valid OpenLDAP release. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5203) [LDAP: error code 32 - No Such Object];
by hiremath47＠gmail.com 26 Oct '07

26 Oct '07

Full_Name: Siddeshawr Version: Version 2.8 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (203.92.60.81) Hi, If I try to add the following entry into the LDAP 'uid=seal_koa/denage(a)denimvage.com' javax.naming.NameNotFoundException: [LDAP: error code 32 - No Such Object]; remaining name at com.sun.jndi.ldap.LdapCtx.mapErrorCode(LdapCtx.java:3013) at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2934) at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2740) at com.sun.jndi.ldap.LdapCtx.c_lookup(LdapCtx.java:998) at com.sun.jndi.toolkit.ctx.ComponentContext.c_resolveIntermediate_nns(ComponentContext.java:152) at com.sun.jndi.toolkit.ctx.AtomicContext.c_resolveIntermediate_nns(AtomicContext.java:342) at com.sun.jndi.toolkit.ctx.ComponentContext.p_resolveIntermediate(ComponentContext.java:381) at com.sun.jndi.toolkit.ctx.ComponentDirContext.p_createSubcontext(ComponentDirContext.java:311) at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.createSubcontext(PartialCompositeDirContext.java:248) at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.createSubcontext(PartialCompositeDirContext.java:236) at javax.naming.directory.InitialDirContext.createSubcontext(InitialDirContext.java:176) Please suggest on the same. Regards, Siddeshwar

1 0

Re: (ITS#5195) ssf not available during sasl bind
by russell-openldap＠stuart.id.au 26 Oct '07

26 Oct '07

I have now tried: security tls=128 sasl=128 It didn't work. All the commands below work without the 'security' option. ldapsearch -x -ZZ -D "uid=openldap,dc=auth,dc=lubemobile,dc=com,dc=au" -w "$(ssu cat /etc/libnss-ldap.secret)" -b "dc=pwd,dc=lubemobile,dc=com,dc=au" "(uid=it)" ldap_bind: Confidentiality required (13) additional info: SASL confidentiality required Which, when I think about it may be reasonable. I am apparently saying I require a sasl ssf of 128, and obviously I don't have that. This was a surprise though: ldapsearch -ZZ -U "openldap" -b "dc=pwd,dc=lubemobile,dc=com,dc=au" "(uid=it)" ldap_sasl_interactive_bind_s: Confidentiality required (13) additional info: SASL confidentiality required Is that a bug? Anyway, bugs aside, assuming I now have some idea how it works its useless for my application. I want to insist that userPassword to be encrypted when sent and received, be that via CRAM-MD5 or friends or by using TLS, but clear text is fine for the rest of the information in the ldap database, and in fact anonymous connections unencrypted connections are the rule for VPN access. The 'security' option applies to all connections. Anyway, to state the problem as clearly as I can, I can't see how to do the following combination of things: . Allow anonymous access over unencrypted connections for the bulk of the database. . Allow simple binds, but they must be over encrypted connections to protect userPassword. . Allow sasl binds over unencrypted connections, but the must not use clear text. . Not particularly relevant to me, but it would be nice to allow sasl binds using clear text if they are over an encrypted connection. The patch does this of course, but if there is some other way then the patch is irrelevant, except perhaps from a usability point of view.

1 0

Re: (ITS#5195) ssf not available during sasl bind
by russell-openldap＠stuart.id.au 25 Oct '07

25 Oct '07

On Thu, 2007-10-25 at 16:33 -0700, Howard Chu wrote: > There are no shortcuts when it comes to security. If you don't take the time > to understand it you'll get it wrong, period. That's true of all systems, no > matter how simple or complex - if you don't take the time to understand the > system's security requirements, you will screw up. As in your example above, > which should use "auth" access, not "read" access. I am not sure I agree, but to borrow your words a discussion about short cuts to security seems irrelevant to this ITS, as is whether I made a typo in my example. The rather long winded rant is relevant in one minor way (sorry about the length). In your original counter example, you said correctly "slap_auxprop_lookup" is doing an internal search and thus doesn't expose the password. The fact that I would have to know that in order to realise that "acl ... by tls_ssf=" doesn't do what I want is what I was railing against. It is purely a technical detail. When plain text is used, the password is sent over the connection. The fact happens not to be the copy in the slapd database (and thus as you say the copy in the database is infinitely secure) is irrelevant to me, the user. You said that if "you don't take the time to understand [the] security [model], you will get it wrong, period". Well there is room for movement at both ends. You can insist the user spends a long time understanding slapd's security model, or you can make the model easier to understand. I think the patch does the latter. If you think I am wrong, ie it makes slapd configuration harder to understand, then by all means reject it.

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