On Tue, Jul 28, 2009 at 1:24 PM, Howard Chu<hyc@symas.com>
wrote:>> Date: Tue, 28 Jul 2009 07:20:01 -0700
>> From: Techie<techchavez@gmail.com>
>
>> On Tue, Jul 28, 2009 at 2:13 AM, John A. Sullivan
>> III<jsullivan@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@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@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>