RE: Newbie question: setting userPassword field

["Dan" <dan@fatcanary.com.au>]

Slowly becoming clearer.  So then there would be LDAP clients that would
authenticate a user's login and password by attempting to bind?

For example, I hook up an LDAP module to Apache.  It asks me for a username
and password.  I type in "dan", and "mypassword".  Depending on the module,
it may then attempt to bind as "dn=dan, o=fatcanary" using the password
"mypassword".  The OpenLDAP then hashes "mypassword" and compares it with
the userPassword field.  If the hash matches, I'm authenticated; if not, I'm
denied access.  Am I getting warmer here?

Dan Makovec
e-mail  dan@fatcanary.com.au <mailto:dan@fatcanary.com.au>
ICQ     1398090
Every day is a gift, that's why the present is so named





> -----Original Message-----
> From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
> Sent: Tuesday, 8 February 2000 13:02
> To: Dan
> Cc: openldap-software@OpenLDAP.org
> Subject: RE: Newbie question: setting userPassword field
>
>
> At 12:54 PM 2/8/00 +1030, Dan wrote:
> >Hmm, this may solve my prob...
> >
> >> No.  OpenLDAP 1.x recognized hashed values but will not generate them.
> >> We have no plans to add any new features to OpenLDAP 1.2.
> >
> >When you say "recognized"
>
> I mean that the slapd's bind implementation will recognize userPassword
> values of the form "{scheme}hashedValue", apply the hash function
> implied by the scheme to the asserted password and compare the result
> to stored hashedValue as part of the authentication process.
>
> For all other operations (compare,add,modify), userPassword is
> treated as a user attribute type of caseExactString syntax.
>
> >I understand the implications of this - plaintext
> >passwords would then be transmitted over the net - but this does
> not concern
> >me for the moment.
>
> The implication is that applications must provide hashed values
> for all non-bind operations.
>