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

    Note

    ACIs with add permissions also apply to child entries created in future.
  • 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 creates a set with the ACIs from dc=example,dc=com and ou=People,dc=example,dc=com. Directory Server builds the list of applicable ACIs bottom-up from the target entry up to the top suffix. However, consider this list as a set, and the client application should not anticipate any order into ACI evaluation.
    The server selects the ACIs that match the resource entry that creates the final set of applicable ACIs from this initial set. Then it first evaluates the ACIs that deny permission. If a DENY ACI has been successfully evaluated, the operation fails. If no DENY ACI is found, Directory Server checks if an ACI exists that grants ALLOW permissions. If at least one of the ACIs allows access, Directory Server grants access. If no ACI grants ALLOW permissions, Directory Server refuses access, and the operation fails.

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.
Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.