targetattr

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 Server:

(targetattr="*"): Indicates that the access control rule applies to all user attributes. Operational attributes are not automatically included in this set.
(targetattr="+"): Indicates that the access control rule applies to all operational attributes. User attributes are not automatically 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 does 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 Server distinguishes between these two types of attributes in its access control implementation. The PingDirectory 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.

(targetattr="+")

To include all user and all operational attributes, use both symbols.

(targetattr="*||+")

If you need to target a specific operational attribute rather than all operational attributes, include it in the values of the targetattr clause.

(targetattr="ds-rlim-size-limit")

If you want to target all user attributes and a specific operational attribute, use them in the targetattr clause.

(targetattr="*||ds-rlim-size-limit")

The following sample ACIs are placed on the dc=example,dc=com tree. The first ACI 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";)

When assigning access to user and operational attributes, it is easy to inadvertently create an access control instruction that grants far more capabilities to a user than originally intended. The following example shows the implications of the PingDirectory server not distinguishing between these attributes.

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 common rule and seems harmless, but has serious consequences for a PingDirectory 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 several 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 allows them to edit any other attributes in their own entry, including those excluded by rules like uid and employeeNumber in the previous example, or add, modify, or delete any entries below his or her own entry.

Because the Server does not automatically include operational attributes in the target attribute list, these types of ACIs do not present a security risk for it. 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.