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 to the 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 in the 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 ou=Groups,dc=example,dc=com branch.