[Auth_ldap] Intermittent auth trouble

[Ace Suares]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Brent,

> Hmmm - well, the basic problem that my patch fixed was that a given
> httpd child process would stay bound as the "last successfully
> authenticated user" when doing the search (of the search/bind) for the
> next user who just happends to hit that httpd child.  (The correct
> behavior before searching should be to always first rebind as the
> AuthLDAPBindDN, or as anonymous if you aren't using that).   So, if
> given your LDAP directory ACL, some users can't search for and find
> other users based on the LDAP search filter you're using in the
> AuthLDAPURL, then the auth_ldap bug would cause what you are seeing -
> that is, if the "last successfully authenticated user" on the httpd
> process you hit is one of the users who can't "see" other users.  So,
> applying my patch actually might fix your problem. It will not hurt
> anything, so try it and see what happens.

I'll do that. My users are seperated quite strictly - a user can't even look 
outside the tree they are in. Some users can only see themselves. Pretty much 
the whole reason why I use ldap ;-)

So I'll try to compile auth_ldap with your patch. I have been using 
precompiled binaries (Suse rpm's) so this is gonna be fun.

Also, if this problem is really there, than why do so few other people report 
that problem ?????


> Also, if your directory ACL is complex in terms of DN's being
> visible/non-visible anoymously, you might want to create a privileged DN
> that has all the necessary rights to search for and find all the users
> who will authenticate to your web site  - again, the needed ACI's would
> be based on whatever filter criteria you are using in the LDAP URL - and
> then use that DN in an AuthLDAPBindDN and -Password.   This notion is
> applicable to any LDAP authentication mechanism (web or non-web) that
> uses the search/bind technique to first find a DN and then bind as that
> DN to test the credentials.  And this is probably the most common
> technique out there, by far.

I have these at the top of my ACL's:

access to attrs=objectclass,uid
	by anonymous search stop
	by * none break

access to attrs=entry,cn
	by anonymous read stop
	by * none break

It means that anonymous can search objectclass and uid, and can read cn and 
entry. This should allow for finding the correct uid (with a filter on 
objectclass) and to read the dn and the cn. (Why the cn is readable, escapes 
me at the moment).

the 'break' after 'by * none' makes sure that any onymous (or non-anonymous) 
connections go down on the rest of the ACL's to figure out what access they 
have. :-)


Thanks again,

ace

website: http://www.qwikzite.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux)

iD8DBQE/sBzMy7boE8xtIjURAvUDAJ0TSa2ZlJ9pvFG2/+cjxYqlOlVudwCeMuJR
hMkeQZW51ZuTg0IG5Dv2V2s=
=ksDS
-----END PGP SIGNATURE-----