Directory
Writing ACL's in OpenLDAP can be one of the most difficult tasks to undertake. One needs to really consider what goals they are trying to accomplish with their ACLs. The order of the ACL's can be of particular importance as well.
Here are some acls, which commentary on what they do.
access to dn.base=""
by * read
This ACL gives incoming connections the ability to read the rootDSE. It is very important to allow this, as incoming clients may need to obtain information from the base level (such as your supported SASL Mechs). The ".base" portion of the ACL restricts clients to querying only the top level
access to dn.subtree="cn=monitor"
by * read
This ACL says anyone can read from the monitor subtree. The monitor backend provides statistics that can be used to graphically represent how the LDAP server is behaving. The ".subtree" of the ACL means that all entries starting at "cn=monitor" can be read.
access to *
by dn.base="cn=replicator,cn=Service,cn=Applications,dc=stanford,dc=edu" sasl_ssf=56 write
by group.base="cn=Supervisor,cn=Applications,dc=stanford,dc=edu" sasl_ssf=56 read
by group.base="cn=ldapAdmin,cn=Applications,dc=stanford,dc=edu" sasl_ssf=56 read
by dn.base="cn=RegistryDataAuditor,cn=Service,cn=Applications,dc=stanford,dc=edu" sasl_ssf=56 read
by * break
This ACL is a bit more complex. It says that the above DN's have full read into the database. "sasl_ssf" says that a SASL security factor of 56 (56-bit encryption) is required for the operation to be successful. The "group.base" portion says that these entries are static groups, which have membership (See sample LDIF file). The "by * break" line means that if a bound entity does not match the above rules, continue evaluating the ACL file.
access to dn.children="cn=Accounts,dc=stanford,dc=edu" filter=(suSeasStatus=active) attrs=suSeasSunetID,suMailDrop
by dn.base="cn=StanfordMailRouter,cn=Service,cn=Applications,dc=stanford,dc=edu" sasl_ssf=56 read
by * break
This ACL adds a few more dimensions. The "filter" piece says that if "suSeasStatus" has a value "active", proceed. The "attrs" part says which attributes can be returned.
access to dn.children="cn=people,dc=stanford,dc=edu" attrs=suPrivilegeGroup val.regex="^stanford:.+"
by group.base="cn=WebAuthPrivileged,cn=applications,dc=stanford,dc=edu" sasl_ssf=56 read
by group.base="cn=WebAuthGeneral,cn=applications,dc=stanford,dc=edu" sasl_ssf=56 read
by * break
This ACL states that read access is granted on the suPrivilegeGroup attribute when the values of the attribute start with stanford:. Other values of the suPrivilegeGroup will not be displayed via this ACL.
access to dn.children="cn=people,dc=stanford,dc=edu"
by set.exact="this/uid & user/uid" sasl_ssf=56 read
This ACL states that read access is granted to an entry in the cn=people,dc=stanford,dc=edu subtree when the value for uid in that entry matches the value for uid of the user that bound to the directory server. Sets are extremely powerful in the way in which they can be used. They are not currently well documented, and are somewhat experimental.
access to dn.children="dc=example,dc=com"
by domain.regex=example.com anonymous read
by peername.ip=127.0.0.1 anonymous read
This ACL restricts access to the children of dc=example,dc=com to anonymous searches from hosts residing in example.com and to anonymous searches from localhost.
It is very important to read the slapd.access(5) manpage, as it details ACL's and the possibilites in a very detailed manner.
