Hi, Here is a script I used with 389 that worked fine for me a while back: http://ltb-project.org/wiki/documentation/self-service-password
Greetings, Vincent On Tue, Feb 23, 2016 at 2:25 AM, William Brown <wibr...@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) > > > > > 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 >
-- 389 users mailing list 389-users@%(host_name)s http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org
