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.
On 23 Feb 2016 14:54, "Janet Houser" <houser(a)nso.edu> wrote:
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> 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
> > 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
> > 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
> likely to read the userPassword field into the PHP, then it will hash and
> 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
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
> 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
> 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
> 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 PHP?
> William Brown
> Software Engineer
> Red Hat, Brisbane
> 389 users mailing list
389 users mailing list
389 users mailing list