Ignore the blank message. Email fail.

On Mon, 2016-02-22 at 16:25 -0700, Janet Houser wrote:
> Thanks William,
>
> Hmmm.... then I'm puzzled why things are failing.
>
> For a little more detail as to what's going on....
>
> I was asked to install squirrelmail on a system so user's could read 
> their mail.   I installed
> the change_ldappasswd and everything appears working except for actually 
> changing the
> password.
>
> The system connects to my 389-ds server and a successful anonymous bind 
> occurs.   It
> reads my password properly because if I enter it wrong, it will tell me 
> so.   But when I try to
> change the password, I get an error saying it couldn't retrieve my old 
> password from the LDAP
> server.
>
>  From an old post 
> (http://comments.gmane.org/gmane.mail.squirrelmail.user/28454)  it claims
> that this error means that the php script couldn't find the password 
> field in the search results.
>
> I'm going off the assumption that because I don't see the userpassword 
> SSHA field when I do
> a ldapsearch, this means it can't either, so it fails.

Okay, I'm thinking this is a pretty old script. See, what's trying to do is
likely to read the userPassword field into the PHP, then it will hash and strcmp
on the php side, if it's the same, it says "yeah, you are who you claim to be"
then it writes direct to the userPassword field (which we block in 389 anyway)

>
> I'm hacking at the php script to put in print/echo statements to try to 
> pinpoint the problem, but
> I'm thinking that it's doing a second bind to the LDAP server looking 
> for this field.

> I was hoping to try to see if this was the case by making the field 
> available in a ldapsearch.
>
>
> I'll turn my attention back to the php script since I'd rather not 
> compromise security on the
> LDAP server.

Yeah, that's the risk here.

I think the best bet might be to re-write the script or look for an alternative.
You should probably be following this pattern:

ask the user for the password and username
anonymously search for the user via the username and get the dn.
Once you have the dn, do an ldap bind for dn with password.

If that FAILS returns errors about wrong passwords.
If that succeeds, you now have a connection bound as the user.
You can issue an ldap password change extended operation. There will be a php
library that does this already for you.
Once that succeeds, the new password is in place.


The reason for this:

First, you don't compromise the security of the userPassword attribute.

389 retains control of the hashing algo of the user, and it can apply password
policies to the account.


You can simulate this on a command line, with the tool:

ldappasswd

This conducts the steps above.

I hope that this helps you.

--
Sincerely,

William Brown
Software Engineer
Red Hat, Brisbane

--
389 users mailing list
389-users@%(host_name)s
http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org