The current behavior is not considered a bug and hence
it doesn't need "fixing". See RFC 2251/2252/2256.
That's not to say enhancements might be useful to some,
but those should be designed as purely optional. IIRC,
there might be a slapd(8) module (overlay) that provides
such.
Note that slapd(8) compare behavior is consistent with
the LDAP technical specification. It compares the asserted
value with the stored values according to the attribute's
equality matching rule. In the case of userPassword, that
rule is octetStringMatch. So, your patch actually leads to
incorrect behavior.
Note that userPassword can contain multiple values. Where
RFC 2307 hashed values are used (in violation of RFC 2256),
it may be desirable to determine when a particular hashed
value is stored. For instance, a client might want to
test if {crypt}qWe2pXud183 appears as a value of userPassword.
Your patch would break applications attempting to do so.
(Of course, you could tweak your implementation to be
sensitive to whether the assertion value is hashed or
not.)
User applications attempting to use compare to
test user passwords should realize that compare is not
comparable to bind. Bind is the "authenticate to the
directory" function. Compare isn't. Compare shouldn't
be expected to enforce (and doesn't in slapd(8))
Bind-specific authorization checks, nor even have
knowledge of what attribute is used to hold password
information. For all the client knows, the server
could be using authPassword, or some other password
attribute, or some external password store.
Off hand, there are two main uses of compare of userPassword.
One is in support of slapd(8) password management, here our
current behavior is best.
Second is use in user application authentication (as opposed
to directory authentication). In user application authentication,
the user application (client) is responsible for selecting
the password attribute, storing and retrieving values in
accordance with the schema, etc.. Here our current behavior
is best as we shouldn't impose our non-standard behavior
(our use of hashed passwords) upon the application. The
user application expects us to adhere to the schema and
other aspects of the LDAP technical specification.
Kurt
At 07:50 AM 1/24/2006, Oni (Paolo Meschi) wrote:
>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 ITS mailing list)
