The targetattr keyword targets the attributes for which the access control instruction should apply. There are four general forms that it can take in the PingDirectoryProxy Server:
  • (targetattr="*"). Indicates that the access control rule applies to all user attributes. Operational attributes will not automatically be included in this set.
  • (targetattr="+"). Indicates that the access control rule applies to all operational attributes. User attributes will not automatically be included in this set.
  • (targetattr="attr1||attr2||attr3||...||attrN"). Indicates that the access control rule applies only to the named set of attributes.
  • (targetattr!="attr1||attr2||attr3||...||attrN"). Indicates that the access control rule applies to all user attributes except the named set of attributes. It will not apply to any operational attributes.

The targeted attributes can be classified as user attributes and operational attributes. User attributes define the actual data for that entry, while operational attributes provide additional metadata about the entry that can be used for informational purposes, such as when the entry was created, last modified and by whom. Metadata can also include attributes specifying which password policy applies to the user, or overrided default constraints like size limit, time limit, or look-through limit for that user.

The PingDirectoryProxy Server distinguishes between these two types of attributes in its access control implementation. The Directory Proxy Server does not automatically grant any access at all to operational attributes. For example, the following clause applies only to user attributes and not to operational attributes:
(targetattr="*")
You can also target multiple attributes in the entry. The following clause targets the common name (cn), surname (sn) and state (st) attribute:
(targetattr="cn||sn||st")
You can use the "+" symbol to indicate that the rule should apply to all operational attributes, as follows:
(targetattr="+")
To include all user and all operational attributes, you use both symbols, as follows:
(targetattr="*||+")
If there is a need to target a specific operational attribute rather than all operational attributes, then it can be specifically included in the values of the targetattr clause, as follows:
(targetattr="ds-rlim-size-limit")
Or if you want to target all user attributes and a specific operational attribute, then you can use them in the targetattr clause, as follows:
(targetattr="*||ds-rlim-size-limit")
The following ACIs are placed on the dc=example,dc=com tree and allows any user anonymous read access to all entries except the userPassword attribute. The second ACI allows users to update their own contact information. The third ACI allows the uid=admin user full access privileges to all user attributes in the dc=example,dc=com subtree.
aci: (targetattr!="userPassword")(version 3.0; acl "Allow anonymous 
   read access for anyone"; allow (read,search,compare) userdn="ldap:///anyone";)
aci: (targetattr="telephonenumber||street||homePhone||l||st")
  (version 3.0; acl "Allow users to update their own contact info"; 
   allow (write) userdn="ldap:///self";) 
aci: (targetattr="*")(version 3.0; acl "Grant full access for the admin user"; 
  allow (all) userdn="ldap:///uid=admin,dc=example,dc=com";)
An important note must be made when assigning access to user and operational attributes, which can be outlined in an example to show the implications of the Directory Proxy Server not distinguishing between these attributes. It can be easy to inadvertently create an access control instruction that grants far more capabilities to a user than originally intended. Consider the following example:
aci: (targetattr!="uid||employeeNumber")
  (version 3.0; acl "Allow users to update their own entries"; 
    allow (write) userdn="ldap:///self";)
This instruction is intended to allow a user to update any attribute in his or her own entry with the exception of uid and employeeNumber. This ACI is a very common type of rule and seems relatively harmless on the surface, but it has very serious consequences for a Directory Proxy Server that does not distinguish between user attributes and operational attributes. It allows users to update operational attributes in their own entries, and could be used for a number of malicious purposes, including:
  • A user could alter password policy state attributes to become exempt from password policy restrictions.
  • A user could alter resource limit attributes and bypass size limit, time limit, and look-through-limit constraints.
  • A user could add access control rules to his or her own entry, which could allow them to make their entry completely invisible to all other users including administrators granted full rights by access control rules, but excluding users with the bypass-acl privilege, allow them to edit any other attributes in their own entry including those excluded by rules like uid and employeeNumber in the example above, or add, modify, or delete any entries below his or her own entry.

Because the PingDirectoryProxy Server does not automatically include operational attributes in the target attribute list, these kinds of ACIs do not present a security risk for it. Also note that users cannot add ACIs to any entries unless they have the modify-acl privilege.

Another danger in using the (targetattr!="x") pattern is that two ACIs within the same scope could have two different targetattr policies that cancel each other out. For example, if one ACI has (targetattr!="cn||sn") and a second ACI has (targetattr!="userPassword"), then the net effect is (targetattr="*"), because the first ACI inherently allows userPassword, and the second allows cn and sn.