[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: userPassword compare fix
> Trying to compare the userPassword attribute, that contains a crypted
> password (like this: {crypt}qWe2pXud183), with the cleartext password,
> OpenLDAP returned me LDAP_COMPARE_FALSE. However, if I put a cleartext
> password in userPassword, it returns LDAP_COMPARE_TRUE.
> So, as I can see OpenLDAP doesn't crypt (with the proper function) the
> password passed by the client before compare it, as many other LDAP
> servers (like Sun Directory Services) do.
This behavior appears to violate the specs for the compare request;
although in some cases it might be desirable for interoperability issues,
it is not appropriate for slapd(8) as is.
A preferable approach would be to implement it as an overlay that
implements the compare operation as an internal lookup of the underlying
database and compares the asserted value with the existing ones, taking
care of any hashing according to the stored value's hash. Note that
special care should be put in doing the internal search, so that
appropriate access control takes place (ACL_SEARCH, ACL_READ !=
ACL_COMPARE). A reasonable approach would be to:
- perform the internal search as rootdn;
- for each returned value:
- hash the asserted value as required;
- perform an internal compare;
- break in case of success
p.
p.
Ing. Pierangelo Masarati
Responsabile Open Solution
OpenLDAP Core Team
SysNet s.n.c.
Via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
------------------------------------------
Office: +39.02.23998309
Mobile: +39.333.4963172
Email: pierangelo.masarati@sys-net.it
------------------------------------------