---
title: Defining ACIs in user data
description: Most access control rules should be defined in the user data.
component: pingdirectory
version: 11.0
page_id: pingdirectory:pingdirectory_security_guide:pd_sec_define_acis_user_data
canonical_url: https://docs.pingidentity.com/pingdirectory/11.0/pingdirectory_security_guide/pd_sec_define_acis_user_data.html
revdate: September 13, 2023
---

# Defining ACIs in user data

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 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.