Introduction to ACIs

ACIs are stored in the aci operational attribute. The aci attribute is available for use on every entry in the directory, regardless of whether the aci attribute is defined for the object class of the entry. The aci attribute is multi-valued, therefore multiple ACIs can be defined for the same portion of a directory.

ACIs can be used to control access to the following portions of a directory:

• The entire directory

• A subtree of the directory

• Specific entries in the directory, including entries that define configuration tasks

• A specific set of entry attributes

• Specific entry attribute values

ACIs can be used to define access for the following users:

• A specific user

• All users belonging to a specific group or role

• All users of the directory

• A specific client identified by its IP address or DNS name

Scope and Hierarchy in ACIs

ACIs can be created at any node in a directory tree, including the root DSE.

The scope of an ACI can be the target entry, the target entry and its immediate children, or the target entry and all of its children. When no scope is specified, the ACI applies to the target entry and all of its children.

When a server evaluates access permissions to an entry, it verifies the ACIs for the entry and the ACIs for the parent entries back up to the base of the entry’s root suffix. ACIs are not evaluated across chained suffixes on other servers.

Access to an entry in a server must be explicitly granted by an ACI. By default, ACIs define anonymous read access and allow users to modify their own entries, except for attributes needed for security. If no ACI applies to an entry, access is denied to all users except the Directory Manager.

Access granted by an ACI is allowed unless any other ACI in the hierarchy denies it. ACIs that deny access, no matter where they appear in the hierarchy, take precedence over ACIs that allow access to the same resource.

The Directory Manager is the only privileged user to whom access control does not apply. When a client is bound to the directory as the Directory Manager, the server does not evaluate any ACIs before performing operations.

In previous versions of Directory Server, ACIs could not be added or deleted directly under the root DSE. Now this limitation has been removed in Directory Server.

ACI Limitations

The following restrictions apply to ACIs

• If your directory tree is distributed over several servers by using the chaining feature, the following restrictions apply to the use of keywords in access control statements:

  • ACIs that depend on the groupdn keyword must be located on the same server as the group entry. If the group is dynamic, then all members of the group must have an entry on the server too. If the group is static, the members’ entries can be located on remote servers.

  • ACIs that depend on the roledn keyword must be located on the same server as the role definition entry. Every entry that is intended to have the role must also be located on the same server.

  • Attributes generated by a CoS cannot be used in all ACI keywords. Specifically, you should not use attributes generated by CoS with the userattr and userdnattr keywords because the access control rule will not work.

• Access control rules are always evaluated on the local server. You must not specify the hostname or port number of the server in LDAP URLs used in ACI keywords.

• You cannot grant a user the right to proxy as the Directory Manager, nor can you grant proxy rights to the Directory Manager.

• The cache settings used for ensuring that the server fits the physical memory available do not apply to ACI caches, which means that an excessive number of ACIs may saturate available memory.

Default ACIs

The following default ACIs are defined on the root DSE:

• All users have anonymous access to the directory for search, compare, and read operations (except for the userpassword attribute).

• Bound users can modify their own password.

• Users in the group cn=Administrators,cn=config have full access to all entries. This is equivalent to Directory Manager access, although unlike Directory Manager, users in the Administration Group are subject to ACIs.

ACIs and Replication

ACIs are stored as attributes of entries. Therefore, if an entry that contains ACIs is part of a replicated suffix, the ACIs are replicated like any other attribute.

ACIs are always evaluated locally, on the directory server that services the incoming LDAP requests.

When a consumer server receives an update request, the consumer server returns a referral to the master server for evaluation of whether the request can be serviced on the master.

Effective Rights

The effective rights feature can be used to obtain the following information:

• Rights information, including entry level rights, attribute level rights and logging.

• Permissions for write, self write add, and self write delete.

• Logging information for debugging access control problems.

To use the effective rights feature, you must have the access control rights to use the effective rights control and read access to the aclRights attribute.

If a proxy control is attached to an effective rights control-based search operation, the effective rights operation is authorized as the proxy user. Therefore the proxy user needs to have the right to use the effective rights control. The entries that the proxy user has the right to search and view are returned.