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:
- Indicates that the access control rule applies to all user attributes. Operational attributes are not automatically included in this set.
- Indicates that the access control rule applies to all operational attributes. User attributes are not automatically included in this set.
- Indicates that the access control rule applies only to the named set of attributes.
- 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.
You can also target multiple attributes in the entry. The following clause targets the common
cn), surname (
sn) and state (
You can use the
+ symbol to indicate that the rule should apply to all
To include all user and all operational attributes, use both symbols.
If you need to target a specific operational attribute rather than all operational
attributes, include it in the values of the
If you want to target all user attributes and a specific operational attribute, use them in
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
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
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-aclprivilege allows them to edit any other attributes in their own entry, including those excluded by rules like
employeeNumberin 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
Another danger in using the
(targetattr!="x") pattern is
that two ACIs within the same scope could have two different
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