Hi Janet,

You're welcome.
When it comes to these things that many people use, an online search will help to find you what you need often.

Let us know how it works out.

Greetings,
Vincent

On 23 Feb 2016 14:54, "Janet Houser" <houser@nso.edu> wrote:
Hi Vincent,

Thanks for the link!   It's much appreciated.   I'm afraid my PHP skills leave a lot to be desired....  did I mention I
hate PHP?  ;-)



On 2/23/16 1:14 AM, Vincent Gerris wrote:
Hi,

Here is a script I used with 389 that worked fine for me a while back:

Greetings,
Vincent

On Tue, Feb 23, 2016 at 2:25 AM, William Brown <wibrown@redhat.com> wrote:
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)

That's my take on it too.  It does the initial bind anonymously, but from the write statements
it looks like it's finding the user properly, and the password.   It looks to go through a second
bind to change the password and it's looking for the hashed password.   Since this isn't a field
that's shown with an ldap search, it's failing.

I had tried to modify the script to not require the hashed password field, but my php skills are....
lacking.....    Did I mention I hate PHP?

>
> 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.


Thanks for the steps and pointers, it helps.    I'll see if I can update the script.   The link you sent should help me
code the appropriate commands.        Yeah...  did i mention I hate PHP?   :-)

Cheers,




--
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



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


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