1.2. Introduction to Directory Server

Red Hat Directory Server is comprised of several components. The core of the directory itself is the server that implements the LDAP protocol. Red Hat Directory Server has a client-side graphical user interface on top of the LDAP server that allows end-users to search and change entries in the directory. Other LDAP clients, both third-party programs and custom programs written using the Mozilla LDAP SDK and the OpenLDAP SDK, can be used with Red Hat Directory Server or to integrate other applications with Red Hat Directory Server.
When the Red Hat Directory Server is installed, it has these elements:
  • The core Directory Server LDAP server, the LDAP v3-compliant network daemon (ns-slapd) and all of the associated plug-ins, command-line tools for managing the server and its databases, and its configuration and schema files. For more information about the command-line tools, see the Directory Server Configuration, Command, and File Reference.
  • Admin Server, a web server which controls the different portals that access the LDAP server. For more information about the Admin Server, see Administrator's Guide.
  • Directory Server Console, a graphical management console that dramatically reduces the effort of setting up and maintaining the directory service. For more information about the Directory Server Console, see Administrator's Guide.
  • SNMP agent to monitor the Directory Server using the Simple Network Management Protocol (SNMP). For more information about SNMP monitoring, see the Directory Server Administrator's Guide.
Without adding other LDAP client programs, Directory Server can provide the foundation for an intranet or extranet. Compatible server applications use the directory as a central repository for shared server information, such as employee, customer, supplier, and partner data.
Directory Server can manage user authentication, create access control, set up user preferences, and centralize user management. In hosted environments, partners, customers, and suppliers can manage their own portions of the directory, reducing administrative costs.

1.2.1. Overview of the Server Frontend

Directory Server is a multi-threaded application. This means that multiple clients can bind to the server at the same time over the same network. As directory services grow to include larger numbers of entries or geographically-dispersed clients, they also include multiple Directory Servers placed in strategic places around the network.
The server frontend of Directory Server manages communications with directory client programs. Multiple client programs can communicate with the server using both LDAP over TCP/IP (Internet traffic protocols) and LDAP over Unix sockets (LDAPI). The Directory Server can establish a secure (encrypted) connection with SSL/TLS, depending on whether the client negotiates the use of Transport Layer Security (TLS) for the connection.
When communication takes place with TLS, the communication is usually encrypted. If clients have been issued certificates, TLS/SSL can be used by Directory Server to confirm that the client has the right to access the server. TLS/SSL is used to perform other security activities, such as message integrity checks, digital signatures, and mutual authentication between servers.

Note

Directory Server runs as a daemon; the process is ns-slapd.

1.2.2. Server Plug-ins Overview

Directory Server relies on plug-ins to add functionality to the core server. For example, a database layer is a plug-in. Directory Server has plug-ins for replication, chaining databases, and other different directory functions.
Generally, a plug-in can be disabled, particularly plug-ins the extend the server functionality. When disabled, the plug-in's configuration information remains in the directory, but its function is not used by the server. Depending on what the directory is supposed to do, any of the plug-ins provided with Directory Server can be enabled to extend the Directory Server functionality. (Plug-ins related to the core directory service operations, like back end database plug-in, naturally cannot be disabled.)
For more information on the default plug-ins with Directory Server and the functions available for writing custom plug-ins, see the Directory Server Plug-in Guide.

1.2.3. Overview of the Basic Directory Tree

The directory tree, also known as a directory information tree (DIT), mirrors the tree model used by most file systems, with the tree's root, or first entry, appearing at the top of the hierarchy. During installation, Directory Server creates a default directory tree.
Layout of Default Directory Server Directory Tree

Figure 1.1. Layout of Default Directory Server Directory Tree

The root of the tree is called the root suffix. For information about naming the root suffix, see Section 4.2.1, “Choosing a Suffix”.
After a standard installation, the directory contains three subtrees under the root suffix:
  • cn=config, the subtree containing information about the server's internal configuration.
  • o=NetscapeRoot, the subtree containing the configuration information of the Directory Server and Admin Server.

    Note

    When additional instances of Directory Server are installed, they can be configured not to have an o=NetscapeRoot database; in that case, the instances use a configuration directory (or the o=NetscapeRoot subtree) on another server. See the Directory Server Installation Guide for more information about choosing the location of the configuration directory.
  • cn=monitor, the subtree containing Directory Server server and database monitoring statistics.
  • cn=schema, the subtree containing the schema elements currently loaded in the server.
  • user_suffix, the suffix for the default user database created when the Directory Server is setup. The name of the suffix is defined by the user when the server is created; the name of the associated database is userRoot. The database can be populated with entries by importing an LDIF file at setup or entries can be added to it later.
    The user_suffix suffix frequently has a dc naming convention, like dc=example,dc=com. Another common naming attribute is the o attribute, which is used for an entire organization, like o=example.com.
The default directory tree can be extended to add any data relevant to the directory installation. For more information about directory trees, see Chapter 4, Designing the Directory Tree.
Expanded Directory Tree for Example Corp.

Figure 1.2. Expanded Directory Tree for Example Corp.