18.2. ACI Placement

Directory Server stores ACIs in the multi-valued aci operational attribute in directory entries. To set an ACI, add the aci to the corresponding directory entry. Directory Server applies the ACIs:
  • Only to the entry that contains the ACI, if it does not have any child entries.
    For example, if a client requires access to the uid=user_name,ou=People,dc=example,dc=com object, and an ACI is only set on dc=example,dc=com and not on any child entries, only this ACI is applied.
  • To the entry that contains the ACI and to all entries below it, if it has child entries. As a direct consequence, when the server evaluates access permissions to any given entry, it verifies the ACIs for every entry between the one requested and the directory suffix, as well as the ACIs on the entry itself.
    For example, ACIs are set on the dc=example,dc=com and the ou=People,dc=example,dc=com entry. If a client wants to access the uid=user_name,ou=People,dc=example,dc=com object, which has no ACI set, Directory Server first validates the ACI on the dc=example,dc=com entry. If this ACI grants access, Directory Server then verifies the ACI on ou=People,dc=example,dc=com. If this ACI successfully authorizes the client, they can access the object.

Note

ACIs set in the rootDSE entry apply only to this entry.
An ACI created on an entry can be set not to apply directly to that entry but rather to some or all of the entries in the subtree below. The advantage of this approach is that general ACIs can be placed higher in the directory tree to have effect on entries located lower in the tree. For example, an ACI that targets entries that include the inetOrgPerson object class can be created at the level of an organizationalUnit entry or a locality entry.

Note

Minimize the number of ACIs in the directory tree by placing general rules at high level branch points. To limit the scope of more specific rules, place them to leaf entries as closely as possible.