On Tue, Jul 28, 2009 at 1:24 PM, Howard Chu<hyc at symas.com> wrote: >> Date: Tue, 28 Jul 2009 07:20:01 -0700 >> From: Techie<techchavez at gmail.com> > >> On Tue, Jul 28, 2009 at 2:13 AM, John A. Sullivan >> III<jsullivan at opensourcedevel.com> wrote: >>> >>> On Mon, 2009-07-27 at 23:29 -0700, Techie wrote: >>>> >>>> Hello, >>>> I am trying to altogether eliminate anonymous access to my directory. >>>> However in doing this my authentication fails unless....I add a binddn >>>> and bindpw to the ldap.conf on the clients. >>>> As I understand it "bindpw" is inappropriate according to the OpenLDAP >>>> architects. > > I don't know which conversation you're referring to, but certainly bindpw is > not valid in the OpenLDAP ldap.conf. It may be valid in PADL's ldap.conf, > but that's a different story. (As for why two completely different config > files have the same name, well, we blame PADL for usurping the name and > sowing endless confusion. Newer distros have started using different names > like "nssldap.conf" to cut down on the confusion.) > >>>> So my situation right now looks like this. I have a ldap.conf >>>> populated with a binddn and bindpw entry. >>>> This allows me to remove anonymous access and authenticate to the >>>> directory with ldap user credentials. >>>> This is what I want, I just do not want to store a username and pass >>>> in the ldap.conf file. > >>>> However if I remove this binddn and bindpw entry, and I disallow >>>> anonymous access, I am unable to authenticate against the directory >>>> using ldap user credentials. Even though upon attempting to login i am >>>> supplying valid LDAP user credentials it cannot find the user because >>>> it initially binds as "nobody" or 'dn="" in the access log and is >>>> unable to locate attributes do to the lack of anonymous access. > >>>> Is there a way to have LDAP use the credential of the user logging in >>>> to bind to the directory initially. > >>>> What are my options? >>>> I can force SASL GSSAPI but it it not ideal in my situation. > > You can also use SASL DIGEST-MD5, which doesn't require any special > infrastructure for deployment. Of course, here you're talking about the > login which is handled by pam_ldap; you'll still need a set of service > credentials that nss_ldap can use for its own queries. Ok so a service credential and clear text password is necessary in the case of login with pam_ldap/nss_ldap. I was thinking there was similar functionality to the Solaris LDAP client that stores the NSldap bindpasswd hashed in a local file. >>> >>> <snip> >>> As far as I know (and that's not very far), that's the way it is. How >>> else would the client be able to query the directory. We made sure we >>> did not use a sensitive password and also ensured the ldap.conf file was >>> NOT world readable. We also had to implement some custom ACIs to >>> replace anonymous access and, I'm surprised how many applications simply >>> assume anonymous access; we had to do a bit of dancing on a per >>> application basis to make them work. Hope this helps - John >>> -- >>> John A. Sullivan III >>> Open Source Development Corporation >>> +1 207-985-7880 >>> jsullivan at opensourcedevel.com >>> >>> http://www.spiritualoutreach.com >>> Making Christianity intelligible to secular society >> >> John, >> It does help, thank you. Currently I use an account for the binddn >> that has only read access to a subset of attributes. not much damage >> can be done. I will keep searching and see what I find. > > That's really the best approach - use a dedicated account for nss queries > and limit its privileges... Thank you for the clarification. I will make the adjustments. > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > > -- > 389 users mailing list > 389-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users >
