On Monday 15 September 2008 11:19:01 Kick, Claus wrote:
>I progressed further, but still haven't reached stage where I can use
>Through, the proxy setup I could able to query ldap, but unable to use
it for authentication. For example,
>ldapsearch -x -h ldapserver -LLL -b dc=internal,dc=phg,dc=com,dc=au
>is Successful, but id nazeerm fails (returns id: nazeerm: No such
>Here is ldap.conf file on client machine.
We had a similar problem (on Solaris though), the problem was that the
ACLs for slapd were too tight.
Bear in mind that we use OpenLDAP as internal user management tool (in a
DMZ), so security isnt too much an issue.
We now use:
access to * by * read
access to attrs=userpassword by self write by * read by anonymous auth
access to dn.subtree="<subtree for the group mapping>" by * read by *
This ACL set provides absolutely no security in the order they are above ...
(I know this is partly redundant, never got to change it on the
production system since we do not have downtimes very often).
Access to userpassword was necessary for "su" commands to succeed.
Only if you didn't have PAM configured correctly on the LDAP clients.
Access to the group subtree was necessary for getting the proper
user-to-group mapping via the "id" or "getent" commands.
If you don't use a proxy user ...
I would suggest to start with widely opened gates and then gradually
closing them as far as you can.
I would suggest the other approach (open access as necessary, and definitely
don't use 'access to * by * read' as the first rule.