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:
Here is a script I used with 389 that worked fine for me a while back:
On Tue, Feb 23, 2016 at 2:25 AM, William Brown <wibrown(a)redhat.com
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
> their mail. I installed
> the change_ldappasswd and everything appears working except for
> changing the
> The system connects to my 389-ds server and a successful
> occurs. It
> reads my password properly because if I enter it wrong, it will
> so. But when I try to
> change the password, I get an error saying it couldn't retrieve
> password from the LDAP
> From an old post
> that this error means that the php script couldn't find the
> field in the search results.
> I'm going off the assumption that because I don't see the
> 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
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
> pinpoint the problem, but
> I'm thinking that it's doing a second bind to the LDAP server
> 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
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
389 retains control of the hashing algo of the user, and it can
policies to the account.
You can simulate this on a command line, with the tool:
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
Red Hat, Brisbane
389 users mailing list
389 users mailing list