You can form the <what> element in two ways. First, the asterisk * by itself indicates all the entries in the directory. Second, you can use a DN string. By default, the DN string is evaluated with regex pattern matching. For example, dn=".*,ou=People, dc=Mycompany,dc=com" would match all entries subordinate to the People OU in the Mycompany directory. Instead of using regex to evaluate the DN string, you can choose several other evaluation options (which OpenLDAP calls target styles) that closely correspond to the basic LDAP search scopes. These evaluation options include base, one, subtree, and children. Each of these options, except children, corresponds to a standard search scope and should be self-explanatory. For example, the one option indicates just the immediate child entries of the DN, not including the DN entry. The children option is similar to subtree in indicating all child entries of the DN, but it doesn't include the DN entry itself.

Further flexibility on the <what> element is supported. You can replace or supplement the DN string option by either an LDAP search filter or an attribute list. The LDAP search filter is formed per the LDAP standard. The attribute list can be any valid attribute(s) of the entries indicated by the DN string or any valid attribute(s) in the entire directory, if the DN string is omitted. You would use the attribute list to control access to the attributes of an entry. In addition to the attributes noted above, two special attribute values are allowed: entry and children. entry denotes the DN of the entry specified by the DN string. children denotes the DN of entries that are subordinate to the DN string specified. The DN is not an attribute in the strict sense, but you must be able to indicate the DN of an entry so access to rename an entry can be controlled.

Several examples of valid <what> elements follow, and these illustrate the diversity of options.

access to dn=".*,ou=People,dc=Mycompany,dc=com" 
    filter=(objectclass=user)

indicates all user entries subordinate to the People OU.

access to dn.base="ou=People,dc=Mycompany,dc=com" 
    attr=entry

indicates the DN of just the People OU.

access to attr=cn 

indicates the cn attribute of every entry.

You can form the <who> element, sometimes called the authorization identity, in a multitude of ways. The two primary options are by a DN string or by inclusion in a special authorization group. The DN string option works as just described.

There are four possible values of the special authorization group: anonymous, users, self, and *. anonymous refers to any user who has authenticated anonymously or has not authenticated. users refers to any user who has successfully authenticated. self refers to an authorization identity that matches the DN of the entry specified in the <what> element.

In addition to these two primary elements, you can include these optional restrictions: inclusion in the membership of a group entry, a match of a DN-valued attribute indicated and the DN of the authorization identity, a match of the DNS domain of the client, a match of the IP address and port of the client, and a match of the server IP address and port that the client uses to connect.

You can use two other optional elements, but these are difficult to describe simply. One is called the set option, and it permits evaluation of complex combinatory logic of multiple expressions of DN strings, the special authorization designations, or DN-valued attributes. You can use the And & and Or | logical operators in these set expressions. The other optional element is called an ACI expression, and I covered it cursorily in Chapter 6.

I've included several examples here of valid <who> elements, and these should illustrate the diversity of options.

by dn=".*,ou=People,dc=Mycompany,dc=com" 

matches any entry within the People OU.

by self 

indicates the authorization identity mapped to the entry associated with the <what>.

by dnattr=manager 

indicates the entry specified by the DN values of the manager attribute of the entry(s) specified in <what>.

by domain=.*.mycompany.com 

indicates a client with any DNS hostname in the mycompany.com DNS zone.

by peername.exact=IP=10.123.123.123:1679 

indicates a client with the IP address indicated, using port 1679.

by group=cn=mygroup,ou=Groups,dc=Mycompany,dc=com 

indicates the entries specified by the DN values of the member attribute of the mygroup entry. Both the member attribute and the groupOfNames object class are assumed by default, but others can be specified.

The <access> element specifies the level of access that should be granted. You can use the set of six common access settings, or you can specify the underlying five discrete privileges incrementally. The six common settings are none, auth, compare, search, read, and write. Table D-1 describes these settings. As listed, the settings are in increasing order of access.

Instead of using the common settings, you can employ the discrete privileges in custom combinations. The underlying five privileges are w (write), r (read), s (search), c (compare), and x (authenticate). You can set them, or add and subtract them from existing privileges, in whatever combination you desire. Later examples demonstrate adding and subtracting from existing privileges and how the order of resolution affect this option.

Evaluation of access control follows a specific order. First, the <what> element is matched, then the <who> element is matched within that <what> directive. The first <what> element to be matched is the only directive that is applied, and any other matching <what> elements that come later are ignored. By default, the first <who> match determines the only <access> applied. Directives can be set at two levels, at the database level (the naming context level) and at the global level. Each of these levels can have multiple directives, and the order in which they appear determines the order of evaluation. Also recall that each <what> directive can have multiple <who> <access> pairs, and again the order in which they appear determines the order of evaluation.

However, the default behavior of the <who> element matching is configurable. Earlier when I stated there were only three primary elements in an access directive, I didn't mention that there is a fourth optional element. This optional element is the <control> element, which tells the access evaluation what to do once a <who> match has been met. The valid values are stop, continue, and break. The stop value is the default value when the <control> element isn't specified. Stop means that once the <who> is matched, no further <who> elements are evaluated. The continue value means that additional <who> elements will be evaluated, and the next <who> element to match will also be applied. Note that the next directive might stop further evaluation by setting a different <control> value.

The following example slapd configuration file demonstrates the multiple access control levels at the database level and at the global level and the flexibility of access control factors. It also shows what a basic configuration file looks like. I've added line numbers to make the commentary easier, but there are no line numbers in a real file.

1 include /usr/local/etc/schema/myschema.schema
2 referral ldap://root.openldap.org
3 access to * by * read

Line 1 defines the schema by including a file. Line 2 configures the default referral. Line 3 is a global access directive and gives read access to anyone, if a directive at the database level isn't matched. This can be dangerous from a security perspective, so think over this approach.

4 database ldbm
5 suffix "dc=mycompany,dc=com"
6 directory /usr/local/var/openldap
7 rootdn="cn=Admin,dc=mycompany,dc=com"
8 rootpw=n01c@ncU
9 index uid,cn,pres,eq,approx,sub
10 index objectclass eq

Line 4 initiates a database, and all that follows applies to this database, until another database is initiated. Line 5 defines the suffix that is in the database, and line 6 is where the database file resides. Lines 7 and 8 set up the all-powerful administrative account. Lines 9 and 10 create indexes for the database. The uid and cn attributes have presence, equality, approximate, and substring operator indexes, and the objectclass attribute has an equality index. Note that all the subsequent access directives apply to this database.

11 access to attr=userPassword
12 by self write
13 by anonymous auth
14 by group=cn=admingroup,ou=Groups,dc=Mycompany,
   dc=com +w

Lines 11 through 14 are the first access directive for the database. This directive matches any access of the userPassword attribute throughout the database. Line 12 allows a user to write (and read) a personal password; but if the entry that is being accessed isn't your own entry, this line won't be matched. Line 13 allows an anonymous user to authenticate, which is important, because prior to authenticating you are anonymous. Note that authenticated users won't match this line. Line 14 allows the entries indicated by the DN values of the member attribute of the groupOfNames admingroup entry to overwrite (but not read) the password of any entry. Note that the order of the <who> directives doesn't really matter in this example, because there isn't an overlap.

15 access to dn.exact="cn=Brian
   Arkills,ou=People,dc=mycompany,dc=com"
16 by dn="cn=Brian
   Arkills,ou=People,dc=mycompany,dc=com" write
17 by peername.exact=IP=10.123.123.123:1679 write

Lines 15 through 17 are the second access directive. Line 15 establishes that this directive applies to accesses to Brian Arkills's entry. Note that accesses of Brian Arkills's password would have been caught by the previous access directive. Line 16 allows Brian Arkills to write to his own entry. The DN string could just as easily have been replaced by self. Line 17 allows clients from the specified IP address and port to write to the entry. This IP address might be Brian's computer, so he has a backdoor in case he forgets his own password but is too embarrassed to have another administrator change it.

18 access to dn=".*,ou=People,dc=Mycompany,dc=com"
   filter=(objectclass=inetOrgPerson)
19 by dnattr=manager write
20 by self write
21 by dn=".*,ou=People,dc=Mycompany,dc=com" read
22 by domain=.*.mycompany.com search

Lines 18 through 22 are the third access directive. Line 18 matches an access to any inetOrgPerson entry that is immediately subordinate to the People OU. Note that both the previous access directives have a possible overlap with this directive, and they might apply prior to this directive, rendering this directive null. Line 19 allows managers to write to their staff's inetOrgPerson entries. Line 20 gives everyone write access to their own entry. Line 21 allows entries in the People OU to read each other's entry. This might not fit with Mycompany's privacy policy as it might be too permissive. Line 22 gives computers in the mycompany.com zone the ability to search the People OU for inetOrgPerson entries. This would only apply if the binding DN was outside of the People OU or anonymous.

23 access to dn.subtree="ou=Documents,dc=Mycompany,
   dc=com"
24 by dnattr=documentAuthor write
25 by users read

Lines 23 through 25 are the fourth access directive. Line 23 determines that this directive applies to entries beneath the Documents OU. Line 24 gives the author of a document write access. Line 25 gives the special users group, which stands for all authenticated users, the ability to read entries in this OU.