[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: unable to bind using encrypted password (ITS#324)

Some additional information:

Before addition of the hashed password support (ie: U-Mich 3.3),
the userPassword and bind credentials where tested for equality
per the syntax of userPassword.  The syntax of userPassword in
U-Mich 3.3 slapd.at.conf was ces.

As the implementation of the hashed password used str* routines,
the hashed password support depends upon the syntax of userPassword
being 'ces'.

For OpenLDAP 1.x users, I recommend they verify userPassword is
defined with the syntax 'ces', ie:
	attribute userpassword ces

For OpenLDAP 2.0, we need to rewrite the password utilities to
expect 'bin' (actually the LDAPv3 equiv) syntax and not to rely
on str* routines (this must be done anyways).

This would be a good project for anyone wanting to get their
feet wet in OpenLDAP slapd programming.


At 08:01 PM 10/15/99 GMT, kurt@boolean.net wrote:
>Likely a something worthy of a FAQ answer...
>Forward to ITS for tracking purposes, will close at submitters request.
>Heath S Hendrickson wrote:
>> I figured out my problem.  It's related to the schema.  I copied
>> Netscape's schema files from DS 4.1 over, modified them so openLDAP
>> would read them in, and went from there.
>> Turns out that the ldbm library has a check that looks at the SYNTAX
>> of the attribute (regardless of what's stored in it).  If it's binary
>> (as the defalut Netscape userPassword attribute is), then it uses
>> a completely different password verfificate routine.  I knew that the
>> lutil library was working correctly because my rootDN passowrd is
>> in crypt format.
>Historically, userPassword has been of type ces in U-Mich/OpenLDAP
>despite the userPasswordSyntax (encoded as octetStringSyntax) as
>indicated by X.520.  This was likely done to allow use of a wider
>variety of search filters.  It is arguable that the syntax should
>be 'bin', however I hesitate changing it (nor the behavior of the
>backends) in 1.x.
>> I checked my schema, and sure enough userPassword was bin.  I changed
>> it to ces, and all seems to be working correctly now.
>> I can't say if this is the problem with the others or not, but it
>> sure made a difference to me.
>> Can you maybe explain why you rely on the SYNTAX instead of checking
>> the value itself to determine if it's binary?
>All values are binary...
>> Does the ldbm backend actually store the values differently?
>> Anyway, you can close out my ITS (I can't seem to figure out how to
>> get into the system as anything other than guest...so I couldn't reply
>> via the ITS to the other problems).
>> thanks,
>> heath
>> On Fri, Oct 15, 1999 at 10:20:31AM -0700, Kurt D. Zeilenga wrote:
>> > First thing to do is to determine what's actually is broken.
>> >   ldappasswd
>> >   slapd
>> >   client
>> >   lutil library
>> >   getpass(3)
>> >
>> > (or combination there of).
>> >
>> > Eliminating getpass(3) is easy.  Don't use prompting to specify
>> > passwords to ldappasswd or any client.  This eliminates the one
>> > client issue.
>> >
>> > Eliminating ldappasswd is easy.  Use a different tool to generate
>> > the hashed passwords.  (like the unix passwd(1) command to generate
>> > crypt passwords (just prepend {crypt} to the passwd(5) password
>> > string) and/or a small script to generate sha1/md5 hashes).
>> >
>> > This document provides perl code for {SHA} and {SSHA} passwords.
>> > Could easily be modified to support other hashs.
>> >   http://developer.netscape.com:80/docs/technote/ldap/pass_sha.html
>> >
>> > There was also examples codes posted to openldap-general recently
>> > in Python and PHP3...
>> >
>> > I suggest testing rootpw first.  If this works, than userPassword
>> > should work (they share the same password verification code).
>> >
>> > Also, note, I assume EVERYONE having these problems is running 1.2.x.
>> > (preferrably 1.2.7 or OPENLDAP_REL_ENG_1_2).  If you are running
>> > another version, the problem could be related
>> > to other factors.  (such as ACLs under 2.0-devel/alpha).
>> >
>> > Also, I assume everyone is running with supplied schema.  If you
>> > changed the syntax of userPassword you will have problems.
>> >
>> > Kurt
>> >
>> > ----
>> > Kurt D. Zeilenga              <kurt@boolean.net>
>> > Net Boolean Incorporated      <http://www.boolean.net/>
>> --
>> ________________________________________________________________________
>> | Heath S. Hendrickson         |        hendrickson@mediaone.net       |
>> |   Full Time Engineer         |        heath@hml.com                  |
>> |   Part Time Webmaster        |                                       |
>> ------------------------------------------------------------------------
>Kurt D. Zeilenga <kurt@boolean.net>
>Net Boolean Incorporated <http://www.boolean.net/>

Kurt D. Zeilenga		<kurt@boolean.net>
Net Boolean Incorporated	<http://www.boolean.net/>