Re: slappasswd compiles but fails to work without --enable-crypt (ITS#2906)

[Kurt@OpenLDAP.org]

At 12:13 PM 1/8/2004, cat@reptiles.org wrote:
>On Wed, 7 Jan 2004, Kurt D. Zeilenga wrote:
>> At 01:00 PM 1/7/2004, cat@reptiles.org wrote:
>> >Full_Name: Cat Okita
>> >Version: 2.1.25
>> >OS: RedHat 7.3
>> >URL: ftp://ftp.openldap.org/incoming/
>> >Submission from: (NULL) (64.241.93.62)
>> >
>> >
>> >When openldap is compiled without the --enable-crypt option [and I suspect that
>> >this may also be true for --enable-sasl], slappasswd is compiled and installed,
>> >but does not function correctly [returns an error message].
>>
>> To function "correctly" requires, in many cases, return the
>> return of an error message.  For your report, I cannot tell
>> whether the output is correct for the input (as you provided
>> neither).
>>
>> Please provide a sample of the input and output and detail
>> why you believe the output to be incorrect.
>
>Looking over things today, it appears that the compilation options were a
>red herring [although setting the default to -only- compile plain text
>authentication is a bit strange, IMHO].
>
>I've solved the problem, but also identified some sources for
>correction:
>
>The documentation states that:
>
>        /usr/local/sbin/slappasswd -h {CRYPT}
>        New password:
>        Re-enter new password:
>        Password generation failed.
>
>should function as expected.

That failed because your shell treated, I assume, { and } as being
special.  However, I agree that the error message could be more
descriptive.

>As it turns out, the format should
>actually be:
>
>        /usr/local/sbin/slappasswd -h '{CRYPT}'
>        New password:
>        Re-enter new password:
>        {CRYPT}DMWh.dJyy54xg

Note that would have failed if the single quotes we're special to
your shell.

>I also tried:
>
>        /usr/local/sbin/slappasswd -h CRYPT
>        New password:
>        Re-enter new password:
>        Password generation failed.
>
>just to see.
>
>The output is incorrect IMHO, because it doesn't indicate why the
>password generation failed in enough detail to indicate the source of
>the issue. Similarly, the documenation (via the man page) is actually
>incorrect.

The documentation, though I will add a clarification, is actually quite
correct.  The user must pass, via their shell, {CRYPT}.  If your shell
requires that to be protected somehow, then that's what you need to do.