Brief Comments On LDAP ACLs (Access Control Lists)

Netscape Directory Server, UMich LDAP-3.3, and OpenLDAP all use a scheme to control access to parts of the LDAP database by specifying one or more internal database attributes, or external real-world attributes. Netscape has renamed ACL to ACI, but the mechanism is basically the same. The biggest difference between Netscape's ACI and LDAP ACL is where the actual control list resides. With Netscape's Directory Server, the ACIs are entries within the LDAP database, usually at the root of the database tree to be controlled. With UMich/OpenLDAP, the ACLs are usually stored in an external file which is included in the LDAP server startup file.

The basic LDAP ACL definition[7, Section 5.3] is shown below. Netscape's ACI has additional attributes.

  <access directive> ::= access to <what>
                 [by <who> <access>] +

  <what> ::= * | [dn=<regex>]
                 [filter=<ldapfilter>]
                 [attrs=<attrlist>]

  <who>  ::= * | self | dn=<regex> |
                 addr=<regex> |
                 domain=<regex> |
                 dnattr=<dn attribute>

  <access> ::= [self]none   | [self]compare |
               [self]search | [self]read |
               [self]write

Samples of ACLs used in the facilities of this report, with some specifics replaced by generic qualifiers, are shown in Figure 8.

Figure 8: Sample Project ACLs

The first ACL restricts all access to the certifiedHost and certifiedAuthor LDAP attributes defined in the LDAP entry for the special newsgroup whose DN begins with the Common Name value of <newsgroup name>. Write, and read, access are granted to the person identified by the owner attribute, which is a ``pointer'' to another LDAP entry (DN). The person associated with the (directory server) Manager DN is given the same access permission.

Access for these privileges requires LDAP password authentication, where the password is stored in the LDAP entry of the authenticating user. The news server using the LDAP database is allowed to read the restricted attributes by either authenticating as the news server LDAP entry DN, or by its IP address matching the value in the by addr specification. All other access attempts for the two specified attributes is denied.

The second ACL in Figure 8 restricts access to the MVSpasswd attribute defined in any LDAP entry. The previous ACL was limited to a single LDAP entry. Here the user (self) identified by their entry's DN and the LDAP administrator both have write and read access. The Samba server which uses the MVSpasswd data is allowed only read access, and its IP address must match that as given in the by addr specification. All other access attempts are denied.

After the owner of any restricted LDAP entry becomes familiar and comfortable with the process, the LDAP administrator may or may not be removed from the specific ACL. It is usually included initially to get the new service operating, and to provide a fall back in case the owner has problems updating their restricted data.