To target a directory entry (and the entries below it), you must use the target keyword. The target keyword can accept a value of the following format:

target="ldap:///distinguished_name

This identifies the distinguished name of the entry to which the access control rule applies. For example:

(target = "ldap:///uid=bjensen,dc=example,dc=com")

Wildcards can be used when targeting a distinguished name using the target keyword. The wildcard indicates that any character or string or substring is a match for the wildcard. Pattern matching is based on any other strings that have been specified with the wildcard.

The following are legal examples of wildcard usage:

Depending on the position of the wildcard, it can apply to the full DN, not only to attribute values. Therefore, the wildcard can be used as a substitute for portions of the DN. For example, uid=andy*,dc=example,dc=com targets all the directory entries in the entire example.com tree with a matching uid attribute and not just the entries that are immediately below the dc=example,dc=com node. In other words, this target matches with longer expressions such as uid=andy,ou=eng,dc=example,dc=com or uid=andy,ou=marketing,dc=example,dc=com.

In addition to targeting directory entries, you can also target one or more attributes included in the targeted entries. This is useful to deny or allow access to partial information about an entry. For example, you could allow access to only the common name, surname, and telephone number attributes of a given entry while denying access to sensitive information such as passwords.

You can specify that the target is equal or is not equal to a specific attribute. The attributes you supply do not need to be defined in the schema. This absence of schema checking makes it possible to implement an access control policy when you set up your directory service for the first time, even if the ACLs you create do not apply to the current directory content.

To target attributes, use the targetattr keyword. The keyword uses the following syntax:

(targetattr = "attribute")

You can target multiple attributes by using the targetattr keyword with the following syntax:

(targetattr = "attribute1 || attribute2 ...|| attributen")

attributeX is the name of the targeted attribute. For example, this targets the common name (cn) attribute:

(targetattr = "cn")

To target an entry's common name, surname, and UID attributes, use the following:

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

The attributes specified in the targetattr keyword apply to the entry that the ACI is targeting and to all the entries below it. If you target the password attribute on the entry uid=bjensen,ou=Marketing,dc=example,dc=com, only the password attribute on the bjensen entry is affected by the ACI because it is a leaf entry.

If, however, you target the tree's branch point ou=Marketing,dc=example,dc=com, then all the entries beneath the branch point that can contain a password attribute are affected by the ACI.

By default, the entry targeted by an ACI containing a targetattr keyword is the entry on which the ACI is placed. That is, putting an ACI such as aci: (targetattr = "uid")(access_control_rules;) on the ou=Marketing,dc=example,dc=com entry means that the ACI applies to the entire Marketing subtree. However, you can also explicitly specify a target using the target keyword:

aci: (target="ldap:///ou=Marketing,dc=example,dc=com")(targetattr="uid")(access_control_rules;)

The order in which you specify the target and the targetattr keywords is not important.

You can use LDAP filters to target a group of entries that match certain criteria. To do this, you must use the targetfilter keyword with an LDAP filter. The syntax of the targetfilter keyword is as follows:

(targetfilter = "LDAP_filter")

LDAP_filter is a standard LDAP search filter. For more information on the syntax of LDAP search filters, see Appendix B, Finding Directory Entries.

For example, suppose that all entries in the accounting department include the attribute-value pair ou=accounting, and all entries in the engineering department include the attribute-value pair ou=engineering subtree. The following filter targets all the entries in the accounting and engineering branches of the directory tree:

(targetfilter = "(|(ou=accounting)(ou=engineering))")

This type of filter targets whole entries. You can associate the targetfilter and the targetattr keywords to create ACIs that apply to a subset of attributes in the targeted entries.

The following LDIF example allows members of the Engineering Admins group to modify the departmentNumber and manager attributes of all entries in the Engineering business category. This example uses LDAP filtering to select all entries with businessCategory attributes set to Engineering:

dn: dc=example,dc=com
objectClass: top
objectClass: organization
aci: (targetattr="departmentNumber || manager")
  (targetfilter="(businessCategory=Engineering)")
  (version 3.0; acl "eng-admins-write"; allow (write)
  groupdn ="ldap:///cn=Engineering Admins, dc=example,dc=com";)

You can use access control to target specific attribute values. This means that you can grant or deny permissions on an attribute if that attribute's value meets the criteria defined in the ACI. An ACI that grants or denies access based on an attribute's value is called a value-based ACI.

For example, you might grant all users in your organization permission to modify the nsroledn attribute in their own entry. However, you would also want to ensure that they do not give themselves certain key roles, such as Top Level Administrator. LDAP filters are used to check that the conditions on attribute values are satisfied.

To create a value-based ACI, you must use the targattrfilters keyword with the following syntax:

(targattrfilters="add=attr1:F1 && attr2:F2... && attrn:Fn,del=attr1:F1 && attr2:F2 ... && attrn:Fn")

When creating an entry, if a filter applies to an attribute in the new entry, then each instance of that attribute must satisfy the filter. When deleting an entry, if a filter applies to an attribute in the entry, then each instance of that attribute must also satisfy the filter.

When modifying an entry, if the operation adds an attribute, then the add filter that applies to that attribute must be satisfied; if the operation deletes an attribute, then the delete filter that applies to that attribute must be satisfied. If individual values of an attribute already present in the entry are replaced, then both the add and delete filters must be satisfied.

For example, consider the following attribute filter:

(targattrfilters="add=nsroledn:(!(nsroledn=cn=superAdmin)) && telephoneNumber:(telephoneNumber=123*)")

This filter can be used to allow users to add any role (nsroledn attribute) to their own entry, except the superAdmin role. It also allows users to add a telephone number with a 123 prefix.

Targeting a single directory entry is not straightforward because it goes against the design philosophy of the access control mechanism. However, it can be done in either of two ways:

You can use the targetattr keyword to specify an attribute that is only present in the entry you want to target, and not in any of the entries below your target. For example, if you want to target ou=people,dc=example,dc=com, and there are not any organizational units (ou) defined below that node, you could specify an ACI that contains targetattr=ou.

A safer method is to use the targetfilter keyword and to specify explicitly an attribute value that appears in the entry alone. For example, during the installation of the Directory Server, the following ACI is created:

aci: (targetattr="*")(targetfilter=(o=NetscapeRoot))(version 3.0; 
     acl "Default anonymous access"; allow (read, search) userdn="ldap:///anyone";)

This ACI can apply only to the o=NetscapeRoot entry.

The risk associated with these method is that your directory tree might change in the future, and you would have to remember to modify this ACI.

You can either explicitly allow or deny access permissions to the directory tree.

Rights detail the specific operations a user can perform on directory data. You can allow or deny all rights, or you can assign one or more of the following rights:

Rights are granted independently of one another. This means, for example, that a user who is granted add rights can create an entry but cannot delete it if delete rights have not been specifically granted. Therefore, when planning the access control policy for your directory, you must ensure that you grant rights in a way that makes sense for users. For example, it does not usually make sense to grant write permission without granting read and search permissions.

This section describes the rights you need to grant to users depending on the type of LDAP operation you want to authorize them to perform.

The permissions granted on individual attributes or entries can affect a broad range of actions; for example, there are several different permissions users must have to search the directory like the following ldapsearch operation:

ldapsearch -h host -s base -b "uid=bkolics,dc=example,dc=com" objectclass=* mail

The following ACI is used to determine whether user bkolics can be granted access:

aci: (targetattr = "mail")(version 3.0; acl "self access to
    mail"; allow (read, search) userdn = "ldap:///self";)

The search result list is empty because this ACI does not grant access to the objectclass attribute. If you want the search operation described above to be successful, modify the ACI to allow read and search access for the mail and objectclass attributes.

aci: (targetattr = "mail || objectclass")(version 3.0; acl "self
    access to mail"; allow (read, search) userdn = "ldap:///self";)

In an ACI statement, the syntax for permissions is allow|deny (rights). rights is a list of 1 to 8 comma-separated keywords enclosed within parentheses. Valid keywords are read, write, add, delete, search, compare, selfwrite, proxy, or all.

In the following example, read, search, and compare access is allowed, provided the bind rule is evaluated to be true:

aci: (target="ldap:///dc=example,dc=com") (version 3.0;acl "example"; 
     allow (read, search, compare) bind_rule;)

To explicitly deny modrdn rights using ACIs, target the relevant entries but omit the targetattr keyword. For example, to prevent the cn=helpDeskGroup,ou=groups,o=example.com group from renaming any entries in the set specified by the pattern cn=*,ou=people,o=example.com, add the following ACI:

aci: (target="ldap:///cn=*,ou=people,o=example.com")
     (version 3.0; acl "Deny modrdn rights to the helpDeskGroup";
     deny(write) groupdn="ldap:///cn=helpDeskGroup,ou=groups,o=example.com";)