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 Admin 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. Resolving the Fully-qualified Domain Name

The Directory Server uses the host name of the machine to supply much of the default information for the instance, such as the instance name and base DN. A fully-qualified domain name is the local host name plus the domain name, such as ldap.example.com.
The setup scripts obtains the host name (ldap) from the local system's gethostname() function, while it obtains the domain name separately, from the system's /etc/resolv.conf file. Specifically, the script looks for the domain name in the first entry in either the search or domain line, whichever is first. For example: 
#
# DNS information
#
search lab.eng.example.com eng.example.com example.com
domain example.com
In this /etc/resolv.conf file, the first parameter is search and the first entry is lab.eng.example.com, so the domain name used by the setup script is lab.eng.example.com.
Any information in the /etc/resolv.conf file must match the information maintained in the local /etc/hosts file. If there are aliases in the /etc/hosts file, such as ldap1.example.com, that do not match the specified domains in the /etc/resolv.conf settings, the setup program cannot generate the correct fully-qualified domain name for the machine as it is used by DNS. All of the default settings then displayed or accepted by the script are wrong, and this can potentially cause the setup to fail.
It is possible to set the fully-qualified domain name for the host manually using an .inf file or by passing the General.FullMachineName argument with the setup command itself. These options are described in Section 1.3, “About the setup-ds-admin.pl Script”. For small deployments or for evaluation, it is possible to use the /etc/hosts file to resolve the host name and IP address (IPv4 or IPv6). This is not recommended for production environments, though.
It is best to have the local hosts file and DNS properly configured for the server. Remote clients and server to server operations like replication require that other machines be able to resolve the host name of the Directory Server's host. Likewise, both TLS/SSL and SASL/Kerberos require an accurate fully-qualified domain name for their configuration.
Configure the DNS resolver and the NIS domain name by the modifying the /etc/resolv.conf, /etc/nsswitch.conf, and /etc/netconfig files, and set the DNS resolver for name resolution.
Edit the /etc/defaultdomain file to include the NIS domain name. This ensures that the fully-qualified host and domain names used for the Directory Server resolve to a valid IP address (IPv4 or IPv6) and that that IP address resolves back to the correct host name.
Reboot the Red Hat Enterprise Linux machine to apply these changes.

1.2.2. Port Numbers

The Directory Server setup requires two TCP/IP port numbers: one for the Directory Server and one for the Admin Server. These port numbers must be unique.
The Directory Server instance (LDAP) has a default port number of 389. The Admin 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 Admin Server ports; you are not required to use the defaults or the randomly-generated ports.

Note

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/SSL), 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/SSL. 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/SSL parameters afterward. For information on how to configure LDAPS, see the Directory Server Administrator's Guide.
The Admin 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 Admin Server cannot run over both HTTP and HTTPS simultaneously. The setup program, setup-ds-admin.pl, does not allow you to configure the Admin Server to use TLS/SSL. To use TLS/SSL (meaning HTTPS) with the Admin Server, first set up the Admin Server to use HTTP, then reconfigure it to use HTTPS.

Note

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.
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.5, “Directory Server User and Group” has more information about the server user ID.

1.2.3. Firewall Considerations

The Directory Server instance may be on a different server or network than clients which need to access it. For example, the Red Hat Certificate System subsystems require a Directory Server LDAP database to store their certificate, key, and user information, but these servers do not need to be on the same machine.
When installing Directory Server, make sure that you consider the location of the instance on the network and that all firewalls, DMZs, and other network services allow the client to access the Directory Server. There are two considerations about using firewalls with Directory Server and directory clients:
  • Protecting sensitive subsystems from unauthorized access
  • Allowing appropriate access to other systems and clients outside of the firewall
Make sure that the firewalls allow access to the Directory Server secure (636) and standard (389) ports, so that any clients which must access the Directory Server instance are able to contact it.

1.2.4. File Descriptors

To increase the maximum number of connections, increment the number of file descriptors on the Linux system and the limit for Directory Server.
  1. To display the maximum number of file descriptors: 
    # sysctl fs.file-max
    If the setting is lower than 64000:
    1. Edit the /etc/sysctl.conf file and set the fs.file-max parameter. For example: 
      fs.file-max = 64000
    2. For the change to take effect, enter: 
      # sysctl --system
  2. To set the number of file descriptors Directory Server can allocate, for example, to 8192:
    1. Verify that the following line exists in the /etc/pam.d/system-auth-ac file or, if it is missing, add it: 
      session     required      pam_limits.so
    2. Add the following line to the /etc/security/limits.conf file: 
      *           -             nofile            8192
    3. Restart Directory Server: 
      # systemctl restart dirsrv.target

1.2.5. 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, nobody on Red Hat Enterprise Linux. Red Hat strongly recommends to change these default values and to create a dirsrv:dirsrv user instead of using the default nobody:nobody user.

Important

The same UID is used for both the Directory Server and the Admin 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 Admin 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) has detailed technical information.

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

1.2.6. 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.7. Directory Administrator

The Directory Server setup also creates an administrator user specifically for Directory Server and Admin Server server management, called the Directory Administrator. The Directory Administrator is the "super user" that manages all Directory Server and Admin 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.8. Admin Server User

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

Important

The default Admin Server user is the same as the Directory Server user, which is nobody. However, Red Hat strongly recommends to use a different user name such as dirsrv for the Directory Server user. If the Admin Server is given a different UID, then that user must belong to the group to which the Directory Server user is assigned.

1.2.9. 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 ldap.example.com, 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.10. 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.11. 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.