Re: ldapsearch doesn't return the userpassword field

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

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.

Thanks for the quick response.   Did I mention I hate PHP?




On 2/22/16 4:05 PM, William Brown wrote:
On Mon, 2016-02-22 at 14:25 -0700, Janet Houser wrote:
Hi Rob,

I appreciate the comment, and that would be a concern, but user's don't
have login access to the client system.   The
php script is written to allow a friendly remote interface for the
nonlinux user to be able to change their password.

There shouldn't be the need to read the password field before you change it. You
should just need to bind, then issue the password change extended operation.

If *must* read the userPassword field, I strong advise that you do not make this
for anonymous.

You should create a service account (simpleSecurityObject), and give only that dn
an aci with read access to the hash.

I still *strongly* advise against this, as you should not need to your
application to behave like this to change a password.



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




[Index of Archives]     [Fedora User Discussion]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora News]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora QA]     [Fedora Triage]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Yosemite Photos]     [Linux Apps]     [Maemo Users]     [Gnome Users]     [KDE Users]     [Fedora Tools]     [Fedora Art]     [Fedora Docs]     [Maemo Users]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Fedora ARM]

  Powered by Linux