Red Hat Training

A Red Hat training course is available for Red Hat Directory Server

18.17. Setting Access Controls on Directory Manager

Having an unconstrained administrative user makes sense from a maintenance perspective. The Directory Manager requires a high level of access in order to perform maintenance tasks and to response to incidents.
However, because of the power of the Directory Manager user, a certain level of access control may be advisable to prevent unauthorized access or attacks from being performed as the root user.
Regular access control rules are applied to the directory tree, the Directory Manager is not a regular user entry, so no (regular) ACIs can be applied to the Directory Manager user. ACIs are applied through a special plug-in configuration entry.

18.17.1. About Access Controls on the Directory Manager Account

Normal access control rules do not apply to the Directory Manager user. The Directory Manager is defined in the dse.ldif file, not in the regular user database, and so ACI targets (Section 18.11, “Defining Targets”) which are based on an entry within a subtree do not include the Directory Manager.
Access controls for Directory Manager are implemented through the RootDN Access Control Plug-in. This plug-in applies to the Directory Server configuration, and therefore can apply some access control rules to the Directory Manager entry.
The plug-in does not define a standard ACL. Some information is already implied, including the target (the Directory Manager entry) and the allowed rights (all of them). The purpose of the RootDN Access Control Plug-in is not to restrict what the Directory Manager can do; the purpose is to provide a level of security by limiting who can log in as Directory Manager (even with valid credentials) based on their location or time.
For this reason, the ACI for the Directory Manager only sets bind rules:
As with other access control rules, deny rules supercede allow rules.


Make sure that the Directory Manager always has the approproate level of access allowed. The Directory Manager may need to perform maintenance operations in off-hours (when user load is light) or to respond to failures. In that case, setting stringent time or day-based access control rules could prevent the Directory Manager from being able to adequately manage the directory.

18.17.2. Configuring the RootDN Access Control Plug-in

Root DN access control rules are disabled by default. The RootDN Access Control Plug-in must be enabled, and then the appropriate access control rules can be set.


There is only one access control rule set for the Directory Manager, in the plug-in entry, and it applies to all access to the entire directory.
  1. Enable the RootDN Access Control Plug-in by setting the nsslapd-pluginEnabled attribute to on. For example:
    # ldapmodify -D "cn=Directory Manager" -W -p 389 -h -x
    dn: cn=RootDN Access Control Plug-in,cn=plugins,cn=config
    changetype: modify
    replace: nsslapd-pluginEnabled
    nsslapd-pluginEnabled: on
  2. Set the bind rules for the access control instruction.
    • rootdn-open-time and rootdn-close-time for time-based access controls.
    • rootdn-days-allowed for day-based access controls.
    • rootdn-allow-host, rootdn-deny-host, rootdn-allow-ip, and rootdn-deny-ip for host-based access controls. These are all multi-valued attributes.
      Deny rules supercede allow rules. For example, if rootdn-allow-host attribute is set to *, and the rootdn-deny-host attribute is set to *, anything in the subdomain is prevented from logging in as Directory Manager, even though the larger domain is allowed.
      Wild cards can be used to allow IP ranges or full domains.
    For example:
    # ldapmodify -D "cn=Directory Manager" -W -p 389 -h -x
    dn: cn=RootDN Access Control Plug-in,cn=plugins,cn=config
    changetype: modify
    add: rootdn-open-time
    rootdn-open-time: 0600
    add: rootdn-close-time
    rootdn-close-time: 2100
    add: rootdn-allow-host
    rootdn-allow-host: *
    add: rootdn-deny-host
    rootdn-allow-host: *
  3. Restart the Directory Server to load the new plug-in configuration.
    # systemctl restart dirsrv@instance