Most access control rules should be defined in the user data.
This is especially true for ACIs that apply to user data. This is accomplished by defining the rules in the ACI operational attribute in entries within the DIT.
For example, the following LDIF modify change record can be used to add an access control rule
ou=People,dc=example,dc=com entry that allows users within that
branch to update their own password.
dn: ou=People,dc=example,dc=com changetype: modify add: aci aci: (targetattr="userPassword")(version 3.0; acl "Allow users to update their own password"; allow (write) userdn="ldap:///self";)
Ideally, ACIs should be placed in the entry that is the base of the subtree to which
it applies. For example, if an ACI applies to entries at or below
ou=People,dc=example,dc=com, then it should be defined in the ACI attribute
ou=People,dc=example,dc=com entry. While such an ACI could be
defined at a higher level in the DIT, like
dc=example,dc=com, and use
the target element to indicate that it applies to a specified subtree, we generally
recommend keeping ACIs as close to the data that they manage as possible.
ACIs cannot be placed in a different subtree than the data to which they apply.
For example, it is not possible to define an ACI in the
ou=People,dc=example,dc=com entry if it is intended to apply to
entries in the