Re: AW: LDAP proxy for AD -- still no solution

[Buchan Milne <bgmilne@staff.telkomsa.net>]

On Monday 15 September 2008 11:19:01 Kick, Claus wrote:
> Hello Nazeer,
>
> >Hi All,
> >I progressed further, but still haven't reached stage where I can use
>
> AD account.
>
> >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
>
> '(uid=nazeerm)'
>
> >is Successful, but id nazeerm fails (returns id: nazeerm: No such
>
> user).
>
> >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 *
> write

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.

Regards,
Buchan