Issue 4366 - userPassword compare fix
Summary: userPassword compare fix
Status: UNCONFIRMED
Alias: None
Product: OpenLDAP
Classification: Unclassified
Component: contrib (show other issues)
Version: unspecified
Hardware: All All
: --- normal
Target Milestone: ---
Assignee: OpenLDAP project
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-01-24 15:50 UTC by Oni (Paolo Meschi)
Modified: 2014-08-01 21:03 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description Oni (Paolo Meschi) 2006-01-24 15:50:42 UTC
Full_Name: Paolo Meschi
Version: 2.X HEAD
OS: Linux
URL: http://www.paolomeschi.com/patches/openldap/openldap-userpassword-compare.patch
Submission from: (NULL) (82.60.63.158)


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 patch should fix this behaviour: 
http://www.paolomeschi.com/patches/openldap/openldap-userpassword-compare.patch

(A copy of this mail has been sent to the devel mailing list)

Comment 1 ando@openldap.org 2006-01-24 18:01:50 UTC
changed notes
moved from Incoming to Contrib
Comment 2 Kurt Zeilenga 2006-01-24 20:45:46 UTC
changed notes
Comment 3 Oni (Paolo Meschi) 2006-01-28 17:13:34 UTC
As suggested I trasformed the patch into an overlay. It can be found
at this address:

http://www.paolomeschi.com/openldap/pwcompare.c

Comment 4 Oni (Paolo Meschi) 2006-01-29 19:22:23 UTC
A fixed version, that include the "hash-compare" configuration option
and a README file, can be found there:

http://www.paolomeschi.com/openldap/pwcompare.tar.gz

Comment 5 Howard Chu 2007-12-15 03:50:32 UTC
I think this is in general a bad idea. It's already noted as such in the 
README, which is fine. The code generally looks pretty good, although it would 
need to be updated for cn=config support. Does anyone else see a reason to 
integrate this and get it working with cn=config?
-- 
   -- 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/

Comment 6 OpenLDAP project 2014-08-01 21:03:27 UTC
not acceptable as submitted (contrib module may be acceptable)
see discussion on -devel