Hi,
I have the following in my slapd.conf:
access to dn.subtree="cn=log" by group/groupOfNames/Member="cn=ldap-admins,ou=Group,dc=soe,dc=ucsc,dc=edu" read
However, anyone (even unbound anonymous users) can access cn=log without any problems. I don't want anyone but ldap-admins to be able to access this subtree.
I'm thinking that I must be missing something really simple here. Am I doing something wrong? Any help is greatly appreciated.
Tim Gustafson BSOE Webmaster UC Santa Cruz tjg@soe.ucsc.edu 831-459-5354
--On Friday, January 30, 2009 4:42 PM -0800 Tim Gustafson tjg@soe.ucsc.edu wrote:
Hi,
I have the following in my slapd.conf:
access to dn.subtree="cn=log" by group/groupOfNames/Member="cn=ldap-admins,ou=Group,dc=soe,dc=ucsc,dc=edu" read
However, anyone (even unbound anonymous users) can access cn=log without any problems. I don't want anyone but ldap-admins to be able to access this subtree.
I'm thinking that I must be missing something really simple here. Am I doing something wrong? Any help is greatly appreciated.
What are your other acls? ACLs are applied as they are reached, so if a previous ACL allows access to cn=log, this one will never get evaluated.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
This is the first ACL in the file.
Tim Gustafson SOE Webmaster UC Santa Cruz tjg@soe.ucsc.edu 831-459-5354
-----Original Message----- From: Quanah Gibson-Mount quanah@zimbra.com
Date: Fri, 30 Jan 2009 17:24:47 To: Tim Gustafsontjg@soe.ucsc.edu; openldap-software@openldap.org Subject: Re: ACL Question
--On Friday, January 30, 2009 4:42 PM -0800 Tim Gustafson tjg@soe.ucsc.edu wrote:
Hi,
I have the following in my slapd.conf:
access to dn.subtree="cn=log" by group/groupOfNames/Member="cn=ldap-admins,ou=Group,dc=soe,dc=ucsc,dc=edu" read
However, anyone (even unbound anonymous users) can access cn=log without any problems. I don't want anyone but ldap-admins to be able to access this subtree.
I'm thinking that I must be missing something really simple here. Am I doing something wrong? Any help is greatly appreciated.
What are your other acls? ACLs are applied as they are reached, so if a previous ACL allows access to cn=log, this one will never get evaluated.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
Tim Gustafson a écrit :
This is the first ACL in the file.
Tim Gustafson SOE Webmaster UC Santa Cruz tjg@soe.ucsc.edu 831-459-5354
-----Original Message----- From: Quanah Gibson-Mount quanah@zimbra.com
Date: Fri, 30 Jan 2009 17:24:47 To: Tim Gustafsontjg@soe.ucsc.edu; openldap-software@openldap.org Subject: Re: ACL Question
--On Friday, January 30, 2009 4:42 PM -0800 Tim Gustafson tjg@soe.ucsc.edu wrote:
Hi,
I have the following in my slapd.conf:
access to dn.subtree="cn=log" by group/groupOfNames/Member="cn=ldap-admins,ou=Group,dc=soe,dc=ucsc,dc=edu" read
However, anyone (even unbound anonymous users) can access cn=log without any problems. I don't want anyone but ldap-admins to be able to access this subtree.
I'm thinking that I must be missing something really simple here. Am I doing something wrong? Any help is greatly appreciated.
What are your other acls? ACLs are applied as they are reached, so if a previous ACL allows access to cn=log, this one will never get evaluated.
Similarly, other ACLs after this one may grant access to cn=log.
Your current ACL only grants read access to the group ldap-admins. It doesn't specify rights for other users. Explicitly deny access to others like this:
access to dn.subtree="cn=log" by group/groupOfNames/Member="cn=ldap-admins,ou=Group,dc=soe,dc=ucsc,dc=edu" read by * none
Jonathan
Similarly, other ACLs after this one may grant access to cn=log. Your current ACL only grants read access to the group ldap-admins. It doesn't specify rights for other users. Explicitly deny access to others like this
I tried that as well and got the same result. Also, the man page says that each "access to" stanza is implicitly terminated by a "by * none", so specifying this seems to be unnecessary.
But in either case, that also didn't work. I'm working on upgrading my OpenLDAP to the 2.4 branch so that it's not so old anymore, and once I've got that done I'll try again. I'm wondering if the problems I'm encountering have to do with using an older version of the software.
Tim Gustafson BSOE Webmaster UC Santa Cruz tjg@soe.ucsc.edu 831-459-5354
Tim Gustafson wrote:
Similarly, other ACLs after this one may grant access to cn=log. Your current ACL only grants read access to the group ldap-admins. It doesn't specify rights for other users. Explicitly deny access to others like this
I tried that as well and got the same result. Also, the man page says that each "access to" stanza is implicitly terminated by a "by * none", so specifying this seems to be unnecessary.
Absolutely. My bad.
A few things you could check here: 1) If this ACL is in the global context, per-database ACLs will precede it. They may be giving read access. 2) Run with loglevel ACL. The log will detail ACL evaluation, and you'll see exactly which ACL grants access.
Jonathan
- If this ACL is in the global context, per-database ACLs
will precede it. They may be giving read access.
This gave me the hint I needed. Moving the ACL below "bdb cn=log" but above "bdb dc=soe,dc=ucsc,dc=edu" worked. Previously I had all my ACLs at the bottom of slapd.conf together, rather than divided out on a per-DB basis.
Tim Gustafson BSOE Webmaster UC Santa Cruz tjg@soe.ucsc.edu 831-459-5354
openldap-software@openldap.org
-
Jonathan Clarke -
Quanah Gibson-Mount -
Tim Gustafson