Tips on Using ACIs

The following tips can simplify your directory security model and improve directory performance:

• Minimize the number of ACIs in your directory, and use macro ACIs where possible.

  Although Directory Server can evaluate over 50,000 ACIs, managing a large number of ACI statements can be difficult. Excessive ACIs can also have a negative impact on memory consumption.

• Balance allow and deny permissions.

  The default rule is to deny access to any user who has not been specifically granted access. However, you can reduce the number of ACIs by using one ACI that allows access close to the root of the tree and using a small number of deny ACIs close to the leaf entries. This approach can prevent excessive allow ACIs close to the leaf entries.

• Identify the smallest set of attributes on any given ACI.

  If you allow or deny access to a subset of attributes on an object, determine whether the smallest list is the set of attributes that are allowed or the set of attributes that are denied. Then express your ACI so that you are managing the smallest list.

  For example, the people object class contains dozens of attributes. To allow a user to update just a few attributes, write your ACI so that it allows write access for just those few attributes. To allow a user to update all but one or two attributes, create the ACI so that it denies write access for those one or two attributes.

• Use LDAP search filters cautiously.

  Search filters do not directly name the object for which you are managing access. Search filters can therefore result in unexpected results especially as your directory becomes more complex. If you use search filters in ACIs, run an ldapsearch operation with the same filter. This action will ensure that you know what the results of the changes mean to your directory.

• Do not duplicate ACIs in different parts of your directory tree.

  Look for overlapping ACIs. Imagine that you have an ACI at your directory root point that allows a group write access to the commonName and givenName attributes. Imagine also that you have another ACI that allows the same group write access to just the commonName attribute. In this scenario, consider reworking your ACIs so that only one attribute grants write access for the group.

  As your directory grows more complicated, accidental overlapping of ACIs becomes increasingly common. If you avoid ACI overlap, security management becomes easier and the total number of ACIs in your directory is reduced.

• Name your ACIs.

  While naming ACIs is optional, giving each ACI a short, meaningful name makes managing your security model easier.

• Use standard attributes in user entries to determine access rights.

  As far as possible, use information that is already part of standard user entries to define access rights. If you must create special attributes, consider creating the attributes as part of a role or Class of Service (CoS) definition. For more information about roles and CoS, see Chapter 11, Directory Server Groups and Roles, in Oracle Fusion Middleware Reference for Oracle Directory Server Enterprise Edition and Chapter 12, Directory Server Class of Service, in Oracle Fusion Middleware Reference for Oracle Directory Server Enterprise Edition.

• Group ACIs as closely together as possible.

  Limit ACI placement to your directory root point and to major directory branch points. If you organize ACIs into groups, the total list of ACIs is easier to manage and the total number of ACIs can be kept to a minimum.

• Avoid using double negatives, such as deny write if the bind DN is not equal to cn=Joe.

  Although this syntax is acceptable to the server, the syntax can be confusing for an administrator.