Red Hat Training

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

1.2. Considerations Before Setting Up Directory Server

Depending on the type of setup that you perform, you will be asked to provide instance-specific information for both the Administration Server and Directory Server during the installation procedure, including port numbers, server names, and user names and passwords for the Directory Manager and administrator. If you will have multiple Directory Server instances, then it is better to plan these configuration settings in advance so that the setup processes can run without conflict.

1.2.1. Fully Qualified Domain Name Resolution

The fully qualified domain name (FQDN) is the local host name with the domain name appended. For example: The Directory Server installation uses the FQDN to generate default values, such as the instance name, the admin domain, and the LDAP base suffix. The setup script uses operating system's gethostname() function to obtain the host and domain name.
When installing a instance behind a proxy server or load balancer, you can set up Directory Server to use a CNAME alias as host name.
If you are using DNS, verify that forward and reverse resolution works correctly:
  • Resolving the host name:
    # host has address
    When using a CNAME record, verify that it resolves correctly:
    # host is an alias for has address
  • Resolving the IP:
    # host domain name pointer
For further information about domain names and network configuration, see the Red Hat Enterprise Linux 7 Networking Guide.

1.2.2. Port Numbers

The Directory Server setup requires two TCP/IP port numbers: one for the Directory Server and one for the Administration Server. These port numbers must be unique.
The Directory Server instance (LDAP) has a default port number of 389. The Administration Server port number has a default number of 9830. If the default port number for either server is in use, then the setup program randomly generates a port number larger than 1024 to use as the default. Alternatively, you can assign any port number between 1025 and 65535 for the Directory Server and Administration Server ports; you are not required to use the defaults or the randomly-generated ports.


While the legal range of port numbers is 1 to 65535, the Internet Assigned Numbers Authority (IANA) has already assigned ports 1 to 1024 to common processes. Never assign a Directory Server port number below 1024 (except for 389/636 for the LDAP server) because this may conflict with other services.
For LDAPS (LDAP with TLS), the default port number is 636. The server can listen to both the LDAP and LDAPS port at the same time. However, the setup program will not allow you to configure TLS. To use LDAPS, assign the LDAP port number in the setup process, then reconfigure the Directory Server to use LDAPS port and the other TLS parameters afterward. For information on how to configure LDAPS, see the Red Hat Directory Server Administration Guide.


When determining the port numbers you will use, verify that the specified port numbers are not already in use by running a command like netstat.
The Administration Server runs on a web server, so it uses HTTP or HTTPS. However, unlike the Directory Server which can run on secure (LDAPS) and insecure (LDAP) ports at the same time, the Administration Server cannot run over both HTTP and HTTPS simultaneously. The setup program,, does not allow you to configure the Administration Server to use TLS. To use TLS (meaning HTTPS) with the Administration Server, first set up the Administration Server to use HTTP, then reconfigure it to use HTTPS.


The Directory Server Console has a known limitation in the following scenario:
  • Multiple Directory Server instances are installed on one host.
  • Each instance is bound to a different local network interface.
  • All instances use the same port number, such as 389.
If all conditions are met, the Directory Server Console is only able to connect to the first instance. To work around the problem, run the Directory Server instances on different ports.
If you are using ports below 1024, such as the default LDAP port (389), you must run the setup program and start the servers as root. You do not, however, have to set the server user ID to root. When it starts, the server binds and listens to its port as root, then immediately drops its privileges and runs as the non-root server user ID. When the system restarts, the server is started as root by the init script. The setuid(2) man page has detailed technical information.
Section 1.2.4, “Directory Server User and Group” has more information about the server user ID.

1.2.3. Opening the Required Ports in the Firewall

To open the Directory Server ports in the firewall on the server:
  1. Make sure the firewalld service is running.
    • To find out if firewalld is currently running:
      # systemctl status firewalld
    • To start firewalld and configure it to start automatically when the system boots:
      # systemctl start firewalld
      # systemctl enable firewalld
  2. Open the required ports using the firewall-cmd utility. For example, to open the Directory Server default ports in the default firewall zone:
    # firewall-cmd --permanent --add-port={389/tcp,636/tcp,9830/tcp}
    For details on using firewall-cmd to open ports on a system, see the Red Hat Security Guide or the firewall-cmd(1) man page.
  3. Reload the firewall configuration to ensure that the change takes place immediately:
    # firewall-cmd --reload

1.2.4. Directory Server User and Group

The setup process sets a user ID (UID) and group ID (GID) as which the servers will run. The default UID is a non-privileged (non-root) user, dirsrv on Red Hat Enterprise Linux. The default GID is also dirsrv.


The same UID is used for both the Directory Server and the Administration Server by default, which simplifies administration. If you choose a different UID for each server, those UIDs must both belong to the group assigned to Directory Server.
For security reasons, Red Hat strongly discourages you from setting the Directory Server or Administration Server user to root. If an attacker gains access to the server, he might be able to execute arbitrary system commands as the root user. Using a non-privileged UID adds another layer of security.
Listening to Restricted Ports as Unprivileged Users

Even though port numbers less than 1024 are restricted, the LDAP server can listen to port 389 (and any port number less than 1024), as long as the server is started by the root user or by init when the system starts up. The server first binds and listens to the restricted port as root, then immediately drops privileges to the non-root server UID. setuid(2) man page has detailed technical information.

Section 1.2.2, “Port Numbers” has more information on port numbers in Directory Server.

1.2.5. Directory Manager

The Directory Server setup creates a special user called the Directory Manager. The Directory Manager is a unique, powerful entry that is used to administer all user and configuration tasks. The Directory Manager is a special entry that does not have to conform to a Directory Server configured suffix; additionally, access controls. password policy, and database limits for size, time, and look-through limits do not apply to the Directory Manager. There is no directory entry for the Directory Manager user; it is used only for authentication. You cannot create an actual Directory Server entry that uses the same DN as the Directory Manager DN.
The Directory Server setup process prompts for a distinguished name (DN) and a password for the Directory Manager. The default value for the Directory Manager DN is cn=Directory Manager. The Directory Manager password must contain at least 8 characters which must be ASCII letters, digits, or symbols.

1.2.6. Directory Administrator

The Directory Server setup also creates an administrator user specifically for Directory Server and Administration Server server management, called the Directory Administrator. The Directory Administrator is the "super user" that manages all Directory Server and Administration Server instances through the Directory Server Console. Every Directory Server is configured to grant this user administrative access.
There are important differences between the Directory Administrator and the Directory Manager:
  • The administrator cannot create top level entries for a new suffix through an add operation. Either adding an entry in the Directory Server Console or using ldapadd, a tool provided with OpenLDAP. Only the Directory Manager can add top-level entries by default. To allow other users to add top-level entries, create entries with the appropriate access control statements in an LDIF file, and perform an import or database initialization procedure using that LDIF file.
  • Password policies do apply to the administrator, but you can set a user-specific password policy for the administrator.
  • Size, time, and look-through limits apply to the administrator, but you can set different resource limits for this user.
The Directory Server setup process prompts for a user name and a password for the Directory Administrator. The default Directory Administrator user name is admin. For security, the Directory Administrator's password must not be the same as the Directory Manager's password.

1.2.7. Administration Server User

By default, the Administration Server runs as the same non-root user as the Directory Server. Custom and silent setups provide the option to run the Administration Server as a different user than the Directory Server.


The default Administration Server user is the same as the Directory Server user, which is dirsrv. If the Administration Server is given a different UID, then that user must belong to the group to which the Directory Server user is assigned.

1.2.8. Directory Suffix

The directory suffix is the first entry within the directory tree. At least one directory suffix must be provided when the Directory Server is set up. The recommended directory suffix name matches your organization's DNS domain name. For example, if the Directory Server host name is, the directory suffix is dc=example,dc=com. The setup program constructs a default suffix based on the DNS domain or from the fully-qualified host and domain name provided during setup. This suffix naming convention is not required, but Red Hat strongly recommends it.

1.2.9. Configuration Directory

The configuration directory is the main directory where configuration information — such as log files, configuration files, and port numbers — is stored. These configuration data get stored in the o=NetscapeRoot tree. A single Directory Server instance can be both the configuration directory and the user directory.
If you install Directory Server for general directory services and there is more than one Directory Server in your organization, you must determine which Directory Server instance will host the configuration directory tree, o=NetscapeRoot. Make this decision before installing any compatible Directory Server applications. The configuration directory is usually the first one you set up.
Since the main configuration directory generally experiences low traffic, you can permit its server instances to coexist on any machine with a heavier-loaded Directory Server instance. However, for large sites that deploy a large number of Directory Server instances, dedicate a low-end machine for the configuration directory to improve performance. Directory Server instances write to the configuration directory, and for larger sites, this write activity can create performance issues for other directory service activities. The configuration directory can be replicated to increase availability and reliability.
If the configuration directory tree gets corrupted, you may have to re-register or re-configure all Directory Server instances. To prevent that, always back up the configuration directory after setting up a new instance; never change a host name or port number while active in the configuration directory; and do not modify the configuration directory tree; only the setup program can directly modify a configuration.

1.2.10. Administration Domain

The administration domain allows servers to be grouped together logically when splitting administrative tasks. That level of organization is beneficial, for example, when different divisions within an organization want individual control of their servers while system administrators require centralized control of all servers.
When setting up the administration domain, consider the following:
  • Each administration domain must have an administration domain owner with complete access to all the domain servers but no access to the servers in other administration domains. The administration domain owner may grant individual users administrative access on a server-by-server basis within the domain.
  • All servers must share the same configuration directory. The Configuration Directory Administrator has complete access to all installed Directory Servers, regardless of the domain.
  • Servers on two different domains can use different user directories for authentication and user management.