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. 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. Thank you
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. > > 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. ><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
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. >> >> 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. >> > <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 societyJohn, 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. Thanks again
> 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.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.
On Tue, Jul 28, 2009 at 8:40 AM, Clowser, Jeff<jeff_clowser@fanniemae.com> wrote:>> 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. > > 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@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users >