Each ACI target should be surrounded by parentheses and should have the form (name="<value>").

An access control instruction can have multiple targets by simply placing them one right after another, such as (targetattr="userPassword")(target="ldap:///ou=People,dc=example,dc=com")(targetscope="sub")(targetfilter="(objectClass=person)"). All of the ACI targets must appear at the beginning of the ACI.

targetattr

The targetattr ACI target is used to grant or deny access to a specified set of attributes. If multiple attributes are specified, then they should be separated by two consecutive vertical bars. For example, (targetattr="givenName||sn||cn") indicates that the ACI applies to the givenName, sn, and cn attributes.

The token * can be used as a shorthand notation to indicate all user attributes, but it does not include operational attributes. The token + can be used as a shorthand notation to indicate all operational attributes, but does not include user attributes. If you want an ACI to apply to all user attributes and all operational attributes, then you can use (targetattr="*||+").

It is possible to use the != operator to target all user attributes except a named set. For example, (targetattr!="userPassword") indicates that the ACI targets all userAttributes except userPassword. However, this is potentially dangerous because it is easy for two different ACIs using this construct to cancel each other out. For example, if one ACI includes (targetattr!="userPassword") and a second ACI includes (targetattr!="socialSecurityNumber"), then the net effect might be equivalent to (targetattr="*") because the first target implicitly includes the socialSecurityNumber attribute that you’re trying to exclude with the second, while the second implicitly includes the userPassword attribute that you’re trying to exclude with the first. When access to a specific attribute should not be allowed, it might be better to create an ACI that denies access to that attribute rather than one that grants all access to all attributes except that attribute.

target

The target ACI target is used to indicate that the ACI applies to entries in specified portions of the DIT. The value should be provided as an LDAP URL, but only the DN portion of that URL is used. For example, (target="ldap:///dc=example,dc=com") indicates that the ACI applies to entries at or below “dc=example,dc=com”.

Each ACI can have at most one target. If an ACI defined in the user data does not contain a target element, then the effective target for that ACI would be the DN of the entry in which that ACI is defined. If a global ACI does not contain a target element, then it applies to all entries in the server, including in backends containing non-user data, like the root DSE, configuration, changelog, schema, and monitor backends. The target element can only use the “=” operator. It cannot use the != operator to apply to all portions of the DIT outside of the specified distinguished name (DN).

If an ACI defined in user data includes a target element, then the DN contained in that element must be at or below the DN of the entry that contains that ACI. For example, the ou=People,dc=example,dc=com entry cannot have an ACI that targets entries below ou=Groups,dc=example,dc=com.

If an ACI should not apply to all entries within the target subtree, then the targetscope and targetfilter elements can be used to narrow down the set of applicable entries.

targetscope

The targetscope ACI target is used to specify how much of the target subtree is covered by the ACI. These scopes exhibit the same behavior in ACIs as they do for search operations. Allowed scope values include:

base
Indicates that the ACI only applies to the entry specified by the target DN, and not to any of its subordinates.
onelevel
Indicates that the ACI only applies to entries that are immediate subordinates of the entry specified by the target DN. Neither the target entry, nor any entries that are more than one level below the target entry, are included.
subtree
Indicates that the ACI applies to the entry specified by the target DN, as well as all entries below it (to any depth).
subordinate
Indicates that the ACI applies to all entries below the entry specified by the target DN (to any depth), but does not include the target entry itself.

The targetscope element can only use the “=” operator. It cannot use the != operator. If an ACI does not include a targetscope element, a default value of subtree is assumed.

targetfilter

The targetfilter ACI target is used to identify the set of entries in the target subtree to which the ACI applies based on their content. The value of this element is the string representation of an LDAP search filter, such as “(targetfilter="(objectClass=person)")”.

The targetfilter element can only use the “=” operator; it cannot use the “!=” operator although you can use the “!” operator in the filter itself to negate its meaning. If an ACI does not include a targetfilter element, then all entries within the target subtree and scope are considered applicable.

targattrfilters

The targattrfilters ACI target is used to identify individual attribute values to which the ACI applies. This target is used for write operations, and it can restrict which attributes can be added to or removed from an entry.

The value of this element can have either one or two components. It can specify a set of attribute values that can be added to the entry (which must start with add=), a set of attribute values that can be removed from the entry (which must start with “del=”), or both. If both clauses are present, then they should be separated by a comma.

The content of each clause should be in the form of an attribute name followed by a colon and a search filter that identifies which values will be allowed for that attribute You can target multiple attributes in the same add or delete clause by separating them with a double ampersand &&.

For example, (targattrfilters="add=description:(description=allowedAddDescription) && displayName:(displayName=allowedAddDisplayName), del=description:(description=allowedDeleteDescription)") indicates that the ACI applies to any attempt to add a value of allowedAddDescription to the description attribute, an attempt to add a value of allowedAddDisplayName to the displayName attribute, or an attempt to remove a value of allowedDeleteDescription from the description attribute.

The filters can use a variety of logic for identifying which values are allowed. For example, you can use substring filters that include wildcards to match values that start with, end with, or contain a given substring. You can use a presence filter to indicate that any value is allowed. You can use a greater-or-equal or less-or-equal to indicate a range of allowed values. You can use AND and OR filters to combine multiple filters. You can use a NOT clause to negate a filter.

When processing an add operation, the server requires that the requester have permission to add all of the attribute values. When processing a delete operation, the server requires that the requester have permission to delete all of the attribute values. When processing a modify or modify DN operation, the server requires that the requester have permission to add all values introduced in the update and to delete all values removed in the update.

The targattrfilters element can only use the = operator; it cannot use the != operator.

requestcriteria

The requestcriteria ACI target determines whether an access control rule applies to an operation based on whether that operation matches a given request criteria.

If present in an access control rule, the operator must be either "=" or "!=". The value must be enclosed in quotation marks and it must be the name or full DN of the configuration object that defines the desired request criteria.

For example, let’s say that you want to allow members of the cn=Sales Administrators,ou=Groups,dc=example,dc=com group to be able to read from and write to the entries for the users that are members of the cn=Sales Employees,ou=Groups,dc=example,dc=com group. To do this, you must first create a request criteria object that will match entries for users in the cn=Sales Employees,ou=Groups,dc=example,dc=com group. You can do this with the following configuration change:

dsconfig create-request-criteria \
     --criteria-name "Requests Targeting Sales Employees" \
     --type simple \
     --set "any-included-target-entry-group-dn:cn=Sales Employees,ou=Groups,dc=example,dc=com"

With that request criteria defined, you can use a modification like the following to create the corresponding access control rule:

dn: dc=example,dc=com
changetype: modify
add: aci
aci: (targetattr="*")(requestcriteria="Requests Targeting Sales
  Employees")(version 3.0; acl "Allow sales administrators to manage
  sales employees"; allow (read,search,compare,write)
  groupdn="ldap:///cn=Sales Administrators,ou=Groups,dc=example,dc=com";)

targetcontrol

The targetcontrol ACI target is used to indicate which request controls a requester is allowed to use. The value for this element is the OID for the desired request control, and multiple request control OIDs can be separated by a double vertical bar ||. For example, (targetcontrol="1.2.840.113556.1.4.473||2.16.840.1.113730.3.4.9") is used to target requests that use either or both the server-side sort request control whose OID is “1.2.840.113556.1.4.473” and the virtual list view request control whose OID is 2.16.840.1.113730.3.4.9.

Regardless of the type of control and what action the server can take for requests that contain it, the read right is used when determining whether to allow an operation containing the request control. Although it is technically allowed to include other rights in an ACI that uses the targetcontrol target, only the read right is used in making the determination.

The targetcontrol element can only use the = operator; it cannot use the != operator.

extop

The extop ACI target is very similar to the targetcontrol target, except that it is used to indicate which extended requests a requester is allowed to use. The value can be either a single OID or a list of multiple OIDs separated by double vertical bars.

As with the targetcontrol element, only the read right is considered when determining whether to allow a client to request a given extended operation.
Note:

The server might impose additional access control rights based on the function that the extended operation is to perform. For example, for a client to use the password modify extended operation, the server requires an ACI with an extop target containing the OID 1.3.6.1.4.1.4203.1.11.1, but it also requires that the requester have permission to update the userPassword attribute or whatever password attribute has been configured in the user’s password policy in the target user’s entry.