[389-users] anonymous access

[Clowser, Jeff]

> 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.
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)

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.