Re: Incompatable crypt? (ITS#970)

[Kurt@OpenLDAP.org]

Multiple libraries provide a crypt(3) implementation including
OpenSSL and your system libraries.  The best way to avoid this
problem is to hack OpenSSL not to provide a crypt(3).  If your
system supplies crypt(3) in -lcrypt or -lutil, you might try
reordering of the libraries (by editing config.status and
then runnng it to generate new make files).  However, if
crypt(3) is in -lc, adding an explicit -lc early in the
library set is NOT recommended.

Personally, I recommend hacking OpenSSL.

At 07:15 AM 1/18/01 +0000, brad@mrunix.net wrote:
>Full_Name: Bradford L. Barrett
>Version: 2.0.7
>OS: Linux (Slack71/2.4.0)
>URL: ftp://ftp.openldap.org/incoming/
>Submission from: (NULL) (158.252.70.87)
>
>
>Crypt password problem.  OpenLDAP 1.2.11 worked just fine with crypt passwords
>generated from the /etc/shadow file.. OpenLDAP 2.0.7 doesn't, and appears to
>only work with those generated by slappasswd.  Problem appears to be in the
>hashed strings generated by the two different methods.. example, the password
>"password" looks like the following for each method:
>
>$1$WtcNush3$mMDxjvuWtl73gmfL51QBU0         <-- system password (libcrypt)
>
>sEnmZiwqQzR.U                              <-- slappasswd generated
>
>Hashed passwords of the the first form used to work w/1.2.x, and now
>they don't in 2.0.x... the only ones that will work is the second form.
>I've checked the executables with ldd, and they all show that they
>are linked to libcrypt.so, but it appears that it's not being used
>and instead perhaps an internal crypt function is being used?  I'm
>at a loss here, and there isn't any way for me to easily convert all
>my users passwords to the simplified form of crypt that appears to
>be being used.  Any help would be very much appreciated..