ACI targets specify the set of data to which an ACI applies.
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
.
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)")
”.
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.
Thetargattrfilters
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.
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.
targetcontrol
element, only the read right is considered when
determining whether to allow a client to request a given extended operation. 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.