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

[kurt@boolean.net]

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?

No.

> 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/>