The target of an ACI specifies a set of entries and attributes that are affected by this access control. The target can specify a single attribute of a single entry, every entry, or something in between. Specifying the target component is optional; no target means that the ACI applies to this entry and every child entry. You can use several different methods to designate the target entries. These methods let you target a set of entries in a particular subtree, a set of entries that match a LDAP search filter, a set of attributes, or a type of operation.

You can indicate a set of entries by specifying the DN of the target entries using a slightly modified LDAP URL format. The customizations to this format involve substituting a forward slash (/) for the hostname and port, allowing use of an asterisk as a wildcard for attribute values, and disallowing search filters, options, or controls. For example, both the following targets are valid examples of this method:

(target = "ldap:///cn=Brian Arkills,ou=People,dc=my
    company,dc=com")
(target = "ldap:///cn=*,ou=*,dc=mycompany,dc=com")

The first target matches only my entry, whereas the second matches any entry with a cn attribute directly under any OU entry, under the mycompany.com namespace.

You can indicate a set of entries by specifying an LDAP search filter. Both the following targets are valid examples of this method:

(targetfilter = "(|(objectclass=person)(uid=b*))") 
(targetfilter = "(&(sn=Skywalker)(telephoneNumber=*))")

The first target matches all person entries or entries with a uid beginning with the letter “b.” The second target matches entries with both a surname of Skywalker and a valid telephone number.

You can indicate a set of attributes using a special format. Both the following targets are valid examples of this method:

(targetattr = "cn || sn || telephoneNumber") 
(targetattr = "uid")

The first target matches all the attribute types noted, so every cn, sn, and telephoneNumber attribute would be targeted. The second target matches only the uid attribute.

Finally, you can target specific LDAP operations in combination with a valid LDAP search filter. The following targets are valid examples of this method:

(targattrfilters="add=objectClass:
    (objectClass=person)")
(targattrfilters="del=department:(department=Sales)")

The first target matches the add operation of the objectclass attribute with a value of person, in other words, whenever a person entry is created. The second target matches the delete operation of the department attribute with a value of Sales, or in other words whenever an entry leaves the Sales department.

The ACI heading is essentially the version plus the name of the ACI. The version is a required string that identifies the ACI version. “Version 3.0” is the most recent version. The name is also required and can be any string that identifies the ACI. Use the name to help you remember what the ACI does. An example that shows all the components of an ACI follows the ACI component sections.

The ACI permissions specify what rights apply to the target entries. In addition, the ACI permissions specify whether these rights are allowed or denied. Recall that several ACI statements might apply to a specific target entry and a specific user. Table F-3 identifies all the valid permissions and what rights they give.

The credentials and bind parameters that a user must provide to match the ACI are defined by the ACI bind rules; the bind rule designates the authorization identity. The methods to designate the user affected are varied, like the ACI target component. These methods employ the greatest diversity of access control factors of any LDAP server on the market. They include specifying entries via a variety of means, including client computer identity, day or time, the client authentication method, and a dynamic access control factor that matches the value of attributes.

You can indicate a set of entries by specifying the DN of the target entries using a slightly modified LDAP URL format. This parallels the target method, except the prefix is different. For example,

(userdn = "ldap:///cn=Brian Arkills,ou=People,dc=my
    company,dc=com")

designates my entry as the authorization identity. Wildcards are allowed, just as they were in the parallel target method. In addition to what I described in the earlier section ACI Targets, several special values are supported by this bind rule method. Table F-4 lists these special values.

In addition to directly specifying an entry, you can dynamically target entries via an LDAP URL subtree search filter. Only subtree search filters are allowed via this method. This method lets you specify entries based on whether they match a search filter at the time of access. Who is given access will change over time based on the search filter employed. A valid example of this method is

userdn = "ldap:///dc=mycompany,dc=com??sub? 
    (|(sn=Skywalker)(sn=Solo))"

This example gives access to any entry under the mycompany.com namespace with an sn value of Skywalker or Solo. Wildcards are not allowed in the search filter, but you can use them in the base DN.

You can also indicate a set of entries by specifying the DN of the target group or role in an LDAP URL format. Wildcards are not allowed via this method, nor are any LDAP URL options or search filters. However, you can specify multiple groups by delimiting the group DNs with || characters. The following example illustrates a valid use of this method of targeting groups:

Groupdn="ldap:///cn=Rebel Sympathizers,ou=Groups, 
    ou=People,dc=mycompany,dc=com || cn=Imperial
    Stormtroopers,ou=Groups,ou=People,dc=mycompany,
    dc=com"

This example specifies all the entries that are members of the Rebel Sympathizers group as well as all the entries that are members of the Imperial Stormtroopers group. The following example illustrates a valid use of this method of targeting roles:

roledn="ldap:///cn=Sith,ou=Roles,ou=People, 
    dc=mycompany,dc=com || cn=Jedi,ou=Roles,
    ou=People,dc=mycompany,dc=com"

This example specifies all the entries that are members of the Sith role as well as all the entries that are members of the Jedi role.

The client computer's IP address or DNS hostname can control access. Although this isn't a very effective means of restricting access control by itself, you can use it in conjunction with other bind rule methods to provide greater access control. Wildcards are allowed via these methods. This is a good thing, because adding every IP address on a single basis would make this method unusable otherwise. Valid examples of these methods are

ip="10.87.42.*" 
dns="*.mycompany.com"

The first example allows all client computers on the 10.87.42.0/24 network. The second example allows all client computers with a DNS hostname suffix of “mycompany.com.”

You can use the time of day and day of the week to control access. These methods are useful in combination with other methods, for example to allow only members of the temporary employee group access during business hours. This method is also useful to temporarily disable access during a directory maintenance window. Examples of usage are

dayofweek="tue" 
timeofday="2359"

The first example allows access on Tuesday. Valid values are the first three characters of the name of the day. The second example allows access at 11:59 PM. Valid values are between 0 and 2359, where zero means midnight.

The authentication method negotiated by the client can help to control access. Again, this method is best applied in combination with another method. This method is especially useful in controlling access to entries with highly sensitive data. Requiring SSL is an effective means to protect the privacy of an entry. Most other LDAP servers support SSL but don't give you this level of authorization control. A valid example of this method is

authmethod="sasl DIGEST-MD5" 

This example requires SASL DIGEST-MD5 authentication. Valid values include none, simple, ssl, and sasl (along with the specific sasl method).

You can use a comparison of an attribute value of the target entry and the binding entry as a bind rule method. To pass this bind rule method, the value of the attribute specified on your binding entry must match the value of the corresponding attribute on the target entry. This is the most complex of the methods, but it offers functionality that isn't possible otherwise. For example, say you want to easily give a manager access to all the person entries of the people she manages. Without using this method, you would need several ACI statements—one for each entry. But using this method, you can specify the manager attribute and the value matching the DN of the manager's entry.

This method has two variations, which I describe separately. Typically, you specify the attribute type and value. A valid example of normal usage is

userattr = "favoriteDrink#Bantha Milk" 

This allows entries with favoriteDrink=Bantha Milk to access each other. A more practical example is:

userattr = "relationshipToMycompany#employee" 

The attribute relationshipToMycompany is a custom attribute on person entries, which Mycompany uses to specify the relationship each person has to Mycompany. This example allows all employees of Mycompany access to each other's entries. This might fulfill Mycompany's privacy policy without the use of groups with a large number of members. This specific approach is behind the privacy controls used by Stanford University described in Appendix C.

If the attribute specified has a value with a DN string, the value of the attribute isn't specified. Instead, you must specify one of four options: USERDN, GROUPDN, ROLEDN, or LDAPURL. These options indicate which DN of the user should be compared to the target entry attribute value. USERDN indicates the DN of the user's entry. GROUPDN indicates the DN of one of the groups the user's entry belongs to, including dynamic groups. If dynamic groups are used, this option requires extra processing and can become highly resource intensive. ROLEDN indicates the DN of one of the roles to which the user's entry belongs. If filtered roles are being used, this option can also be highly resource intensive. LDAPURL indicates that the DN of the user's entry should be compared to the value of the attribute. However, the value of the attribute must be an LDAP search filter. The DN of the user's entry then must match the resolution of the LDAP search filter.

A valid example of the DN string option of this method is

userattr = "manager#USERDN" 

This example grants a manager's entry access to her employees' entries.

Now that I have explained all the components of an ACI, let's see what a complete ACI looks like and explore a comprehensive example. An ACI follows this format:

aci: (target1)...(targetX)(version 3.0;acl 
    "name1";permission1 bind_rules1; ... permissionX
    bind_ruleX;) ... (version 3.0;acl "nameX";
    permission bind_rules;)

Note that many components allow multiples. Multiple targets, permissions, and bind rules can be specified. When multiple targets are designated, the resulting target is the union of the targets. Each of the following header/permission/bind rule pairs apply to this union.

Some examples will help illustrate how ACIs translate into practical access controls.

aci: (target="ldap:///uid=barkills,ou=Accounts, 
    dc=Mycompany,dc=com")(targetattr=*)
(version 3.0; acl "Self access"; allow (read,
    search, compare) userdn="ldap:///self";)

This example targets my user account and all attributes of my entry. The header designates the version and names the ACI for reference. The permissions allow read, search, and compare access. The bind rules specify that the authorization identity must match the target entry. So I'd be able to write to my own entry with this ACI. This aci attribute would need to be set on my entry or on a parent entry anywhere above my entry.

Where an ACI is applied is important and can simplify the target. For example, if I want to give all account entries write access to themselves, the following ACI on ou=Accounts,dc=Mycompany,dc=com would do the trick:

aci: (targetattr=*)(version 3.0; acl "Self access"; 
    allow (write) userdn="ldap:///self";)

The following example gives members of the Sales-HR-admins group access to all the members of the Sales HR admins department:

aci: (targetfilter="(businessCategory=Sales)") 
    (version 3.0; acl "Sales-HR-admins-write"; allow
    (write) groupdn ="ldap:///cn=Sales HR
    admins,ou=Groups,ou=People,dc=Mycompany,dc=com";)

The following example is an ACI on ou=People,dc=Mycompany, dc=com. It gives users the right to add any role, except the Admin role, to their own entry. This ACI additionally restricts the use of this right with an exhausting list of conditions. The add operation must be made using SSL encryption, from a client computer with a DNS host suffix of Mycompany.com, on a weekday during normal business hours, and from a specific class C IP address range.

aci: (targetattr="*") (targattrfilters= 
    "add=nsRoleDN:(nsRoleDN != "cn=Admin,dc=Mycompany,
    dc=com")") (version 3.0; acl "Add Roles"; allow
    (write) userdn= "ldap:///self" and
    dns="*.Mycompany.com" and (authmethod="ssl") and
    (dayofweek="Mon,Tues,Wed,Thu,Fri") and (timeofday
    >= "0800" and timeofday <= "1700") and
    (ip="10.87.42.*");)

The following example ACI is applied to ou=Documents,dc=Mycompany,dc=com. It gives all authors full control over all their document entries:

aci: (targetattr="*") (version 3.0; acl 
    "Doc author"; allow (all)
    userattr="documentAuthor#USERDN";)

You can find more information about ACIs online in the administrator's guide, Chapter 6, at http://docs.sun.com/source/816-5606-10/acl.htm#997355.

As noted in Chapter 8, you use macros to simplify ACI statements by saving a portion of the target's information for later substitution in the bind rule. This section briefly introduces the syntax and specific functionality that macros enable.

You can use three macro variables. Two of these variables match the target's DN, and the other matches an attribute of the target entry. ($dn) is an exact DN match. It saves the DN of the resource targeted in a request for later use. [$dn] is a sub-RDN match. It saves the DN of the target for later use. When substituted in the bind rule, the DN of the targeted resource is examined multiple times, each time dropping the left-most RDN component until a match is found. ($attr.attrName) is an attribute value match. It evaluates to the value of the attribute named by attrName in the target. This can be used in combination with the complex attribute value matching bind rule method. Table F-5 lists each of the variables and the methods that are compatible with each.

The following example grants search access to the members of any cn=Admins group in any subtree to the ou=Groups subtree under the same DN:

aci: (target="ldap:///ou=Groups,($dn), 
    dc=Mycompany,dc=com") (targetattr="*") (version
    3.0; acl "Domain access"; allow (read,search)
    groupdn="ldap:///cn=Admins,ou=Groups,[$dn],
    dc=Mycompany,dc=com";)