[Date Prev][Date Next]
Re: Incompatable crypt? (ITS#970)
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, email@example.com wrote:
>Full_Name: Bradford L. Barrett
>OS: Linux (Slack71/2.4.0)
>Submission from: (NULL) (188.8.131.52)
>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..