Re: (ITS#5191) Corrupted control value when using pagedresults with subordinate database
by ando＠sys-net.it
> 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
---------------------------------------
15 years, 10 months
Re: (ITS#5207) Password checking: external program
by hadmut＠danisch.de
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
15 years, 10 months
Re: (ITS#5207) Password checking: external program
by hyc＠symas.com
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/
15 years, 10 months
Re: (ITS#5207) Password checking: external program
by hadmut＠danisch.de
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
15 years, 10 months
Re: (ITS#5207) Password checking: external program
by bgmilne＠staff.telkomsa.net
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
15 years, 10 months
Re: (ITS#5191) Corrupted control value when using pagedresults with subordinate database
by hyc＠symas.com
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/
15 years, 10 months
Re: (ITS#5207) Password checking: external program
by hadmut＠danisch.de
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
15 years, 10 months
Re: (ITS#5207) Password checking: external program
by hyc＠symas.com
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/
15 years, 10 months
Re: (ITS#5207) Password checking: external program
by bgmilne＠staff.telkomsa.net
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
15 years, 10 months
