Solved!
I used the tip written in http://www.openldap.org/faq/data/cache/320.html, as Dieter Kluenter recommended:
access to attr=userpassword by self =xw by anonymous auth
access to * by self write by users read
Now I can go back to squid and DansGuardian tunning. =D
Thanks Dieter and Buchan. ;D
On Fri, Nov 26, 2010 at 10:53 AM, Dieter Kluenter dieter@dkluenter.dewrote:
Bruno Lamps lampss@gmail.com writes:
Hi,
Thanks Dieter Kluenter and Buchan Milne for answering to this, and
everyone else that is reading this topic. =D
It seems your ACLs are not sufficient for *any* simple binds to thisDN.
Please test the following on your LDAP server: $ ldapwhoami -x -D uid=lamps,ou=usuarios,dc=pisolar -W Until this command works, please don't bother with anything relatedto squid.
Right, this command isn't working for any user, except
cn=admin,dc=pisolar. I'm struggling with /etc/ldap/slapd.conf, to
solve this. I probably tried to make the ACLs a bit too tight, and now
they're choking me. =p
Did you ever test simple binds to your LDAP server as these usersexcept from
squid? It doesn't seem like it ...I use this ldap base to authenticate my GLPI () system. But I think GLPI
just grab all my base, using the ldap admin
password, and transports it to it's mysql database. =/
I'm currently testing different ACLs in /etc/ldap/slapd.conf. Right now,
these are the rules:
access to * by dn="cn=admin,dc=pisolar" write #by anonymous none #by self none by * read
access to attrs=userPassword,shadowLastChange by dn="cn=admin,dc=pisolar" write by anonymous auth by self write by * none
access to dn.base="" by * read
What kind of mistake am I doing there? =S
man slapd.access(5) http://www.openldap.org/doc/admin24/access-control.html http://www.openldap.org/faq/data/cache/189.html
-Dieter
-- Dieter Klünter | Systemberatung http://dkluenter.de GPG Key ID:8EF7B6C6 53°37'09,95"N 10°08'02,42"E