Re: password changes/encryption help

[Matthew Riedel <mriedel@lanl.gov>]

I am having the exact same problem.  I am able to change passowrds 
successfully, but it seems to mutilate them.

I have password-hash {SSHA} explicitly defined in the slapd.conf, but 
it still shows up as a {crypt} password when you view the entry.  A 
typical scenario:

1) Set users password manually, using SSHA on server
2) log in as user on client
3) Change password using "passwd"
4) Look at the user again from the server side, and it shows up as 
{CRYPT} on the server, even though I have password-hash {SSHA} in 
slapd.conf

I also have "pam_password exop" in the /etc/openldap/ldap.conf file

This is Red Hat 9 w/ openldap 2.0.27 and nss_ldap 202

Any one have any ideas out there?

Matt Riedel

On Dec 19, 2003, at 2:05 PM, Brian Jones wrote:

> hi all.
>
> I believe I had this working at some point much earlier in my testing. 
> Now that I'm almost ready for production, of course, it broke :-(
>
> I have linux (currently RH 9) clients that I would like to have change 
> their passwords using the standard passwd binary and pam_ldap. The 
> OpenLDAP server (v 2.1.21 IIRC) is also running RH9, with back-bdb. It 
> has been built with the 'enable-crypt' option.
>
> Passwords can be changed using the command line program 'passwd'. 
> However, the passwords are useless (exiting that user's shell and 
> 'su'ing back to that user with the new password fails with 'Incorrect 
> password'). In my /etc/ldap.conf file, I'm using 'pam_password md5'. 
> I've also tried 'pam_password crypt'. Here's where my confusion 
> starts:
>
> If I have the password crypted on the client before being sent to the 
> server, is the server then going to crypt it *again*, because I 
> compiled with '--enable-crypt'? There's no 'password-hash {}' line in 
> my slapd.conf, but the man page says that SSHA is the default.
>
> This seems like it would mean I should just specify 'pam_password 
> clear' in ldap.conf on the client, and 'password-hash {CRYPT}' on the 
> server. However, this did not work either. Passwords appear to be 
> generated (no errors from the 'passwd' program - and I can verify with 
> an LDAP gui that it's changed), but the resulting passwords can't be 
> used for authentication. The passwords in the directory look like 
> standard 13-character crypt passwords, if that helps.
>
> Any clues hereby solicited.
> brian.