On Tue, Jul 28, 2009 at 8:40 AM, Clowser, Jeff<jeff_clowser@xxxxxxxxxxxxx> wrote: >> On Tue, Jul 28, 2009 at 2:13 AM, John A. Sullivan >> III<jsullivan@xxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/fedora-directory-users > -- 389 users mailing list 389-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-directory-users
