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 Red Hat Directory Server Configuration, Command, and File Reference . Administration Server, a web server which controls the different portals that access the LDAP server. For more information about the Administration Server, see Red Hat Directory Server Administration Guide . Web Console, a graphical management console that reduces the effort of setting up and maintaining the directory service. For more information about the web console, see the Red Hat Directory Server Administration Guide . SNMP agent to monitor the Directory Server using the Simple Network Management Protocol (SNMP). For more information about SNMP monitoring, see the Red Hat Directory Server Administration 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 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 can be used by Directory Server to confirm that the client has the right to access the server. TLS 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 that 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 Red Hat 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. 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. 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 . Figure 1.2. Expanded Directory Tree for Example Corp.

Commands: