An upgrade from 2.3.38 to 2.4.7 seems to have caused my acls to stop working in that anonymous users can no longer search the tree to find their entry to authenticate.
With an acl of
access to dn.base="" by * read
access to dn.base="cn=Subschema" by * read
access to dn.subtree="ou=People,dc=st-andrews,dc=ac,dc=uk" by * read
access to * by users read by anonymous auth
All anonymous searches get insufficient access returned
Logging of ACls shows
=> slap_access_allowed: search access denied by auth(=xd)
Any thoughts on what extra I need for this to work in 2.4?
Cheers, Duncan
Duncan Brannen wrote:
An upgrade from 2.3.38 to 2.4.7 seems to have caused my acls to stop working in that anonymous users can no longer search the tree to find their entry to authenticate.
With an acl of
access to dn.base="" by * read
access to dn.base="cn=Subschema" by * read
access to dn.subtree="ou=People,dc=st-andrews,dc=ac,dc=uk" by * read
access to * by users read by anonymous auth
All anonymous searches get insufficient access returned
Logging of ACls shows
=> slap_access_allowed: search access denied by auth(=xd)
Any thoughts on what extra I need for this to work in 2.4?
Your ACLs are broken. In fact, by moving the "by * auth" into the last rule, you prevent auth'ing for any user whose credentials match any of the previous rules. Either you add "by * auth" to all rules matching potential credentials, or you place a
access to attrs=userPassword by * auth
before any rule that matches potential credentials (note that you may need to enhance the above if any user must be able to change its own password).
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------
Pierangelo Masarati wrote:
Duncan Brannen wrote:
An upgrade from 2.3.38 to 2.4.7 seems to have caused my acls to stop working in that anonymous users can no longer search the tree to find their entry to authenticate.
With an acl of
access to dn.base="" by * read
access to dn.base="cn=Subschema" by * read
access to dn.subtree="ou=People,dc=st-andrews,dc=ac,dc=uk" by * read
access to * by users read by anonymous auth
All anonymous searches get insufficient access returned
Logging of ACls shows
=> slap_access_allowed: search access denied by auth(=xd)
Any thoughts on what extra I need for this to work in 2.4?
Your ACLs are broken. In fact, by moving the "by * auth" into the last rule, you prevent auth'ing for any user whose credentials match any of the previous rules. Either you add "by * auth" to all rules matching potential credentials, or you place a
access to attrs=userPassword by * auth
before any rule that matches potential credentials (note that you may need to enhance the above if any user must be able to change its own password).
p.
Thanks Pierangelo, I've cut most of my rules out to try and get something basic to show the problem I'm having. Anonymous users eg the web server trying to match a uid to a dn, can't search the ou=People branch to get the entry which I'd thought the dn.subtree on ou=People would allow via the by * read line?
With the full acls (which have the attrs=userpassword line) I can authenticate and search fine but not search as an anonymous user which I could with 2.3.38, I'm now trying 2.4.7.
Cheers, Duncan
Duncan Brannen wrote:
I've cut most of my rules out to try and get something
basic to show the problem I'm having. Anonymous users eg the web server trying to match a uid to a dn, can't search the ou=People branch to get the entry which I'd thought the dn.subtree on ou=People would allow via the by * read line?
With the full acls (which have the attrs=userpassword line) I can authenticate and search fine but not search as an anonymous user which I could with 2.3.38, I'm now trying 2.4.7.
Search needs the privileges described in the OPERATION REQUIREMENTS section of slapd.access(5). You need to make sure anonymous has enough privileges, which apparently doesn't. Not sure what's the difference in this area between 2.3 and 2.4; I think the main differences were between 2.2 and 2.3.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------
Pierangelo Masarati wrote:
Search needs the privileges described in the OPERATION REQUIREMENTS section of slapd.access(5). You need to make sure anonymous has enough privileges, which apparently doesn't. Not sure what's the difference in this area between 2.3 and 2.4; I think the main differences were between 2.2 and 2.3.
p.
Thanks again Pierangelo,
Looks like I was missing search on the root dn pseudo entry (?)
Adding access to dn.subtree="dc=st-andrews,dc=ac,dc=uk" by * read
has done the trick. Possibly this was implied in 2.3 and 2.4 is more strict in that respect?
Cheers, Duncan
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it
Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it
Duncan Brannen wrote:
Pierangelo Masarati wrote:
Search needs the privileges described in the OPERATION REQUIREMENTS section of slapd.access(5). You need to make sure anonymous has enough privileges, which apparently doesn't. Not sure what's the difference in this area between 2.3 and 2.4; I think the main differences were between 2.2 and 2.3.
p.
Thanks again Pierangelo,
Looks like I was missing search on the root dn pseudo entry (?)
Adding access to dn.subtree="dc=st-andrews,dc=ac,dc=uk" by * read
has done the trick. Possibly this was implied in 2.3 and 2.4 is more strict in that respect?
I've found some ACLs to be treated more strictly in 2.4 than 2.3. Which is a good thing.
openldap-software@openldap.org