[389-users] anonymous access

[Techie]

On Tue, Jul 28, 2009 at 8:40 AM, Clowser,
Jeff<jeff_clowser at fanniemae.com> wrote:
>> 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.
>
> Hmm... curious way of putting that...
>
>> >> 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.
> <snip>
>
> This is something of a chicken and egg problem.  Most apps
> ask users for a uid and a password, then do a simple bind
> against ldap to validate this.  However, a simple bind requires
> a dn, rather than a uid.  You need to do a search to translate
> the uid to do the bind, but without access to do such a search,
> you can't do the lookup.
>
> It can't safely make assumptions about your
> tree or the format of the dn, so it has to do a search
> to look up the uid to know what dn to bind as, but if you
> turn off anonymous, it can't do that as anonymous, obviously.
>
> You can do one of two things as a minimum:
> 1.  Set up an ACI to allow anonymous to ONLY see the uid
>    (and probably objectclass) attributes.  This will allow
>    *any* app to connect to your directory server as
>    anonymous and do uid lookups.
I did try this yesterday actually, (objectClass, uid ) however the
bind wanted more than this for the login. I need to trace back what
exact attributes it was requesting and fiddle some more.
> 2.  Define a "service account" that is allowed to just
>    read/search the uid and objectclass attributes, and
>    nothing else.  Preferably create a group and set the
>    aci against the group, so that you can make several of
>    these types of service accounts (say, a different one
>    for each app, to easily track their usage separately)
This is essentially what I have going on now, a binddn/pw with limited
read and search access. The group dn thing is a great idea. thanks.
> You probably need to allow objectclass, as well as uid, because
> apps tend to do filters like (&(objectclass=person)(uid=bob)).
> Ultimately, the only way to tell the minimum access your app
> needs is to see in the access logs what it does, and tune
> accordingly.
>
> Option 1 has advantages in that any app can then do this
> translation without the need to config each with a bind dn
> and pwd, but also means anyone that knows about your dir
> server and can connect to it can look up uids, etc.
>
> Option 2 has advantages in that you can create separate
> accounts for separate apps or separate organizational
> groups to track their usage separately.  You can also
> put resource limits on these accounts (for example, you
> might set the nssizelimit on these service accounts to
> 1, so that even if someone compromises the account, it
> can't return more than one entry in a search ever - and
> why would it need to return more than one, if it's
> looking up one uid to get one dn?)  It also means that
> someone without a valid dn and pwd can't see
> anything, so requires more than just the host and port
> of your server.
Interesting, I was not aware that the nssizelimit could be enforced
for individual entries. good to know thanks.
>
>
>
>
> --
> 389 users mailing list
> 389-users at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>