openldap-bugs November 2007

openldap-bugs@openldap.org

44 participants
170 discussions

Re: (ITS#5191) Corrupted control value when using pagedresults with subordinate database
by ando＠sys-net.it 01 Nov '07

01 Nov '07

> I disagree. The fact that databases are glued should in no way prevent > paged > results from working. I mean: the current implementation prevents it from working (AFAIK); I see disabling it in case of glued database a legitimate fix of the problem. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5207) Password checking: external program
by hyc＠symas.com 01 Nov '07

01 Nov '07

Hadmut Danisch wrote: > Well, I don't think there's reason to get rude. Please understand that > english is not my first language, and I apologize if I did not meet your > expectations. Nothing rude, just stating a fact. If you don't know the difference between an "entry" and a "value" then you haven't read enough yet. -- -- 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#5207) Password checking: external program
by hadmut＠danisch.de 01 Nov '07

01 Nov '07

Howard Chu wrote: > hadmut(a)danisch.de wrote: >> But this opens other questions: > >> Does slapd support multiple password entries? > > Of course. The schema definition for userPassword says that it is a > multivalued attribute. (Note: "values" not "entries". Seems you need to > do some more reading on LDAP basics.) Well, I don't think there's reason to get rude. Please understand that english is not my first language, and I apologize if I did not meet your expectations. And I did not ask about LDAP in common, I asked about the slapd implementation. So reading LDAP basics would not answer the question. As it was pointed out before, the details of this {SASL} authentication scheme are _not_ documented in the slapd manual or any LDAP basics, but somewhere hidden in the FAQs or even partly undocumented. > slappasswd doesn't know anything about that. slapd checks until it finds > a match. That's what I wanted to know. Obviously, as you yourself point out, that's an implementation detail. Does ldappasswd change all entries or just the one matching the given password? regards Hadmut

1 0

Re: (ITS#5207) Password checking: external program
by hyc＠symas.com 01 Nov '07

01 Nov '07

hadmut(a)danisch.de wrote: > But this opens other questions: > Does slapd support multiple password entries? Of course. The schema definition for userPassword says that it is a multivalued attribute. (Note: "values" not "entries". Seems you need to do some more reading on LDAP basics.) > What does slap (and slappasswd) do if there are multiple entries for > userPassword? Does slapd check them all until one of them matches? slappasswd doesn't know anything about that. slapd checks until it finds a match. -- -- 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#5207) Password checking: external program
by hadmut＠danisch.de 01 Nov '07

01 Nov '07

Buchan Milne wrote: > So you are unaware of the {SASL} scheme for userPassword, where slapd receives > a simple bind, and tries to authenticate the user (as a SASL client) via the > SASL mechanism with the identity following the scheme identifier in the > userPassword attribute. Oh, yeah, I wasn't aware of such a beast. > It is documented to some degree in the FAQ-o-matic. Well, I didn't find a documentation about that, just an article about Kerberos that mentioned that {SASL} thing. FAQ-o-matic seems to be unable to search for '{' and '}'. Putting something in that FAQ-o-matic is certainly a good place to hide it since that FAQ-o-matic uses some really weird sort of ordering, and searching works - if at all - only if you already know what you are looking for. Would be great to put this into the administrator's documentation. However, if that {SASL} scheme does what I believe it does, the client indeed does not need a plugin or SASL support anymore. But this opens other questions: Does slapd support multiple password entries? If I put such a {SASL} thing into my LDAP record, would I still be able to authenticate with a plain password, e.g. by having two entries userPassword: {SSHA}... userPassword: {SASL}... The main problem is that I have to provide several authentication schemes, including good old password authentication (which the SASL daemon was configured to do against the LDAP with encrypted passwords) and some sorts of one time passwords. Storing regular passwords in SASL was no option because cyrus sasl stores passwords as plaintext. So that {SASL} thing could solve my problem as long as it coexists with regular LDAP authentication. What does slap (and slappasswd) do if there are multiple entries for userPassword? Does slapd check them all until one of them matches? regards Hadmut

1 0

Re: (ITS#5207) Password checking: external program
by bgmilne＠staff.telkomsa.net 01 Nov '07

01 Nov '07

On Thursday 01 November 2007 12:15:28 Hadmut Danisch wrote: > Buchan Milne wrote: > > So wouldn't the existing {SASL} scheme for userPassword (which allows a > > simple bind to be authenticated against a SASL identity) be sufficient? > > Not really, because SASL is not just a server plugin, it requires the > client to have SASL (and the plugins) as well. Unfortunately, this is > not the case in most scenarios. So you are unaware of the {SASL} scheme for userPassword, where slapd receives a simple bind, and tries to authenticate the user (as a SASL client) via the SASL mechanism with the identity following the scheme identifier in the userPassword attribute. It is documented to some degree in the FAQ-o-matic. Regards, Buchan

1 0

Re: (ITS#5191) Corrupted control value when using pagedresults with subordinate database
by hyc＠symas.com 01 Nov '07

01 Nov '07

ando(a)sys-net.it wrote: >> When using pagedresults with a subordinate database, the control value of >> the >> returned searchResDone is corrupted. > > AFAIK, paged results is not supposed to work with glued databases, as its > current implementation in both back-bdb/back-hdb and back-sql relies on > internal properties of the storage to keep track of the state of a > search. The most appropriate behavior would be to ignore the control, if > not critical, or reject the operation, if critical. > > I take this ITS as an action to prevent paged results from working when > impacting more than one glued database. I disagree. The fact that databases are glued should in no way prevent paged results from working. After all, the glue only talks to one database at a time. As such, the paged results control's relevance never spans more than a single database at a time. The bug is that after one database has provided all of its entries in response to a request, its response control should be nullified. I.e., a particular database's response control is only needed if that database isn't finished sending entries. Once it has sent all of its entries, it's no longer relevant. Overall the paged results implementation is a suboptimal design; the frontend should do all of the page counting/tracking. It should only ask the backend to provide a state cookie when the current page is full and there are more entries to return. -- -- 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#5207) Password checking: external program
by hadmut＠danisch.de 01 Nov '07

01 Nov '07

Buchan Milne wrote: > So wouldn't the existing {SASL} scheme for userPassword (which allows a simple > bind to be authenticated against a SASL identity) be sufficient? Not really, because SASL is not just a server plugin, it requires the client to have SASL (and the plugins) as well. Unfortunately, this is not the case in most scenarios. Actually, SASL would the the solution of choice if the client supported it, because SASL is able to transmit replies (challenges,...), but this is possible only if all clients support SASL and as long as you are able to install SASL clients on both sides. Reality is, that too many LDAP clients don't support SASL, and even if they do, you are in most cases not able to install SASL library on both sides. Furthermore, SASL mechanisms are limited to password handling. It is sort of tricky or impossible to pass other authentication methods through (e.g. any sort of cookie based authentication). Would be nice if the client could perform just the basic LDAP authentication and the password still be accepted even if it is a cookie, one time password, or any other strange thing. > Well, any implementation of this would have the same problems of the existing > {SASL} scheme, of losing some of the security SASL provides. Well, as I said it would be pretty similar to SASL except for the fact that SASL requires the client to a) support SASL (i.e. has SASL software) b) support the authentication SCHEME (i.e. has the particular SASL plugin) c) has to pass through SASL messages if between client and LDAP (e.g. IMAP servers) which is not the case at the moment. regards Hadmut

1 0

Re: (ITS#5207) Password checking: external program
by hyc＠symas.com 01 Nov '07

01 Nov '07

bgmilne(a)staff.telkomsa.net wrote: > On Tuesday 30 October 2007 12:40:38 hadmut(a)danisch.de wrote: >> Full_Name: Hadmut Danisch >> Version: 2.3.38 >> OS: Linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (85.180.64.93) >> >> >> Hi, >> >> that's a feature request: >> >> Sometimes it is necessary to use other authentication methods than the >> regular password login. E.g. when using an insecure computer in an internet >> cafe to login into a web mail frontend, which accesses an imap server, >> which authenticates against LDAP. It would require to authenticate trough >> one-time-passwords, HTTP-Cookies or other unusual methods. >> >> Actually,SASL provides a way to use other methods like One-time-passwords, >> but is still too limited and there are too many programs (LDAP clients) out >> there that don't support sasl authentication. > > So wouldn't the existing {SASL} scheme for userPassword (which allows a simple > bind to be authenticated against a SASL identity) be sufficient? Simple Bind actually doesn't lend itself well to most one-time-password schemes, because they require the ability for a server to send a challenge string to a client so the client can select/generate the correct OTP. You could kludge this by introducing a new Bind-in-Progress error code but no existing clients would recognize it or know what to do with it. (Too bad the LDAP_SASL_BIND_IN_PROGRESS error code is so specific; it really would have been smarter to minimize differences between SASL Binds and Simple Binds, rather than widen the differences even further.) (The idea being, you could still implement the OTP mech with Simple Bind if the client first sends a Bind request with DN and bogus password - the OTP mech can return an error at that point with the Challenge string in the message text. Then the client can provide that challenge to the user, reprompt for a password, and carry on.) >> Therefore it would be nice if slapd could be configured to do the password >> checking over some external plugin or program, which could do any sort of >> unusual checking. >> This way a user could enter a one time password just as a normal LDAP login >> password, and pass it through the chain of programs, e.g. mailclient - >> maildaemon - LDAP or >> browser - webmailer - imap - LDAP. > > Well, any implementation of this would have the same problems of the existing > {SASL} scheme, of losing some of the security SASL provides. True, but not really an issue for an OTP mechanism; since the password is single-use it doesn't really need any protection. Anyway, slapd *can* be configured to do password checking with external plugins. And there's already several plugins provided in the contrib section of the source tree. Feel free to write more plugins to do whatever kind of checking you want, and submit your plugins back to the ITS. This particular ITS will be closed, the feature already exists. -- -- 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#5207) Password checking: external program
by bgmilne＠staff.telkomsa.net 01 Nov '07

01 Nov '07

On Tuesday 30 October 2007 12:40:38 hadmut(a)danisch.de wrote: > Full_Name: Hadmut Danisch > Version: 2.3.38 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (85.180.64.93) > > > Hi, > > that's a feature request: > > Sometimes it is necessary to use other authentication methods than the > regular password login. E.g. when using an insecure computer in an internet > cafe to login into a web mail frontend, which accesses an imap server, > which authenticates against LDAP. It would require to authenticate trough > one-time-passwords, HTTP-Cookies or other unusual methods. > > Actually,SASL provides a way to use other methods like One-time-passwords, > but is still too limited and there are too many programs (LDAP clients) out > there that don't support sasl authentication. So wouldn't the existing {SASL} scheme for userPassword (which allows a simple bind to be authenticated against a SASL identity) be sufficient? > Therefore it would be nice if slapd could be configured to do the password > checking over some external plugin or program, which could do any sort of > unusual checking. > This way a user could enter a one time password just as a normal LDAP login > password, and pass it through the chain of programs, e.g. mailclient - > maildaemon - LDAP or > browser - webmailer - imap - LDAP. Well, any implementation of this would have the same problems of the existing {SASL} scheme, of losing some of the security SASL provides. Regards, Buchan

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs November 2007