Chapter 1 Welcome to the Directory Server

The Netscape Directory Server provides the centralized directory service upon which your intranet or extranet is based. Your Netscape servers and other directory-enabled applications use the directory service as a common, network-accessible location for storing shared data such as user and group identification, server identification, and access control information. In addition, you can extend the Netscape Directory Server to support your entire enterprise with a global directory service that provides you with centralized management of all your enterprise's resource information.

In this chapter you will learn about the basic Directory Server concepts that you need to use the Directory Server, regardless of the type of installation that you are planning. This chapter includes the following sections:

About the Enterprise—This section describes the concept of the enterprise, especially as the term is used in this guide.

What Is a Directory Service?—This section explains what a directory service is, what it is used for, and the problem set that a directory service is intended to solve. This section also introduces the Lightweight Directory Access Protocol (LDAP).

The Netscape Directory Server—This section describes the Netscape Directory Server and high-level server architecture.

Directory Server Concepts—This section defines the basic terms and concepts that you need to know to install and use a Netscape Directory Server. Concepts include the directory tree, distinguished names, suffix, root entry, root distinguished name, base distinguished name, and secure sockets layer.

However, from the perspective of Directory Server deployment, the enterprise also comprises your organization's resources and activities. You can understand resources to mean the people and groups within your organization as well as the devices (printers, servers, and desktop systems) that your organization uses, and the applications that you run to support your organization (such as a web server or an accounting package). Further, the enterprise also encompasses the physical location(s) in which your organization resides. These differing locations can be separate buildings, cities, states or provinces, or even countries.

You should therefore consider the term the enterprise to mean your entire organization from the buildings that you use, to the software that you run, to the people that you work with.

The basic function of a directory service is to allow you to store information about your enterprise so that it later can be retrieved either by directly searching for that information or by searching for related but more easily remembered information, such as a name.

One fairly well-known client-server directory service is a Domain Name System (DNS) server. Among other things, a DNS server maps computer host names to IP addresses. All of the computing resources on your network are then clients of the DNS server. This allows users of your computing resources to easily locate computers on your network by remembering host names rather than IP addresses, which are a seemingly arbitrary series of numbers to most users.

Of course, a service that stores only two types of information, names and IP addresses, is a limited example of a directory service. A true directory service is used to store virtually unlimited types of information. For example, a true directory service can be thought of as an electronic telephone book in that it almost always contains personal contact information such as a person's name, telephone number, mail address, office number, and so forth. But a Directory Server goes beyond this usage by allowing the enterprise to store other types of information such as:

• physical device information (For example, you can store information about all the printers in your organization, where they reside, whether they are color or black and white, their manufacturer, date of purchase, serial number, and so forth.)
• private employment information such as salary, government identification numbers, home addresses and phone numbers, pay grade, and so forth
• contracts or accounts information, such as the name of the client, final delivery date, bidding information, contract number, and milestone due dates

N+1 Directory Services

Multiple databases serving common directory needs is known as the n+1 directory problem, and it has long been a logistical and financial problem, as well as a security hazard for the enterprise.

Until recently, the basic problem has not been finding and deploying directory services, but rather that enterprises are using too many directory services at once. Most of these directories are bundled as proprietary databases within an application. For example, email systems are traditionally heavy users of directory services. As the many different types of proprietary email systems have spread throughout the enterprise, so too have their accompanying proprietary directory services. These directory services all stored the same types of information: user names, mail addresses, host information, mailbox information, passwords, and so forth.

The problem is that these different directories (some of which were proprietary, some of which were built around standards-based directory services) can not readily share data between themselves. Thus if a user had a mailbox in two different email systems, that user's information usually had to be managed in two different directories. The result is increased costs in both personnel as well as hardware because user information is managed in multiple locations.

Global Directory Services

The concept of a global directory service was invented to solve the n+1 directory problem. The idea was to provide a single, centralized repository of directory information that any application can access. However, the implementation of a global directory service faced some important difficulties. The most serious of these was the question of how the many disparate applications used in the enterprise were supposed to access the directory. The directory would have to be network-based, but what communications protocol would be used for that access?

There were several contenders for the protocol. One of these was the X.500 ISO standard, which is a protocol in use in many enterprises today. X.500 has several advantages that make it attractive for solving the n+1 directory problem. It offers an open communications protocol called the Directory Access Protocol (DAP) that any application can use to access the directory. It also offers an extensible information framework that allows the directory to store virtually any kind of information. Finally, X.500 offers a remarkably robust directory solution that could be scaled to millions of users.

Unfortunately, X.500 also has several limitations. Among these is a dependency on a communications layer that is not the Internet standard TCP/IP protocol, and complicated requirements for directory-naming conventions. The result is a directory strategy that offers the scalability and robustness required by a global directory service but which suffers from expensive administrative costs.

LDAP

LDAP, or the Lightweight Directory Access Protocol, was invented to preserve the best qualities offered by X.500 while reducing the administrative costs. LDAP provides an open directory access protocol running over TCP/IP. It retains the X.500 data model and it is scalable to a global size and millions of entries for a modest investment in hardware and network infrastructure. The result is a global directory solution that is affordable enough to be used by small organizations, but which also can be scaled to support the largest of enterprises.

Without modification, the Directory Server can provide the foundation for your intranet or extranet. Every Netscape server uses the directory as the storage location for shared server information. It is the Directory Server that enables key capabilities such as single-user logon, centralized user and group management, and location independence for your users through its function as a network registry.

Further, you can use the Directory Server to enable a true global directory service that will lower your administrative costs to doing business.

Client-Server Architecture

LDAP directory services are implemented using a client-server architecture. Thus, an LDAP directory service implementation consists of at least one LDAP server and at least one LDAP client. Most directory services consist of multiple LDAP clients communicating to a Directory Server over the network. As directory services grow to include larger numbers of entries or larger numbers of clients spread out geographically, they also include multiple Directory Servers placed in strategic locations around the network.

The Netscape Directory Server product provides the software necessary for an entire directory solution. It includes the Directory Server, which is the server-side software that implements the LDAP protocol, and an HTML interface for end users to search and modify the directory. Other LDAP clients are also available. These include the directory managers in the Netscape Console, and the addressbook feature in Netscape Communicator 4.x. In addition, other LDAP clients are available commercially, and you can write your own LDAP client using the LDAP client SDK that is included with the Netscape Directory Server product. (For an introduction to the LDAP client SDK, see Chapter  10, "Extending Your Directory Service.")

Server-Side Architecture

The Directory Server is essentially a communications engine that stores information in one or more databases. The server is split into two major parts: a front end that is responsible for general network communications and one or more back-end plug-ins that are responsible for database management.

The Directory Server is a multithreaded application that is capable of processing hundreds of thousands of search requests per hour (actual performance is determined by the supporting hardware and network connections). The Directory Server ensures high-performance for search requests by using a database tuned for searching and by building indexes that allow for rapid directory lookups. To further improve performance, the Directory Server caches the most heavily accessed data in memory.

By default, the Directory Server uses a single database plug-in. This database is robust implementation that is capable of managing millions of entries. It supports advanced backup and restore activities that ensure your directory data is always in a consistent state, even in the event of a power outage when data is being written to the database.

For most directory implementations, this default database will support your directory service without any need for customization. However, under some circumstances you may choose to use multiple databases. You can also use the Netscape Directory Server plug-in API to replace this standard database with something else (such as a relational database). This is a non-trivial task that requires a fair amount of development and planning in its own right.

The usage of multiple databases and custom back ends is beyond the scope of this manual. For more information on database usage with your Directory Server, see the Netscape Directory Server Programmer's Guide.

The Directory Tree

The entries in an LDAP directory service are often visualized as being organized in a tree-like structure. This mirrors the tree model used by most file systems, with the tree's root point (first entry) appearing at the top of the hierarchy. This is referred to as the directory tree:

A similar term, Directory Information Tree (DIT), is often used to refer to an enterprise's directory tree. However, DIT is strictly defined to mean the global X.500 directory tree. In the X.500 view, there is only one DIT and all directory services are considered to be managing portions of that single DIT.

The concept of a single, global DIT is not as important to LDAP-based directory services as it is to X.500 directory services. Therefore, to avoid confusion with this X.500 term (which many directory architects are familiar with), the Netscape Directory Server documentation simply refers to the directory tree, which is meant to be all or part of the directory tree in use in your enterprise.

Distinguished Names

Just as a file path uniquely identifies a file within a file system, a directory entry is uniquely identified within the directory tree using a distinguished name (DN). A DN identifies the entry by using a series of comma-separated attributes and attribute values. However, the path specification for DNs is in reverse order from a traditional file system. That is, where a file system typically traces the path to the file from left to right with the file's actual name specified in the right-most component, a DN specifies the left-most component as being the actual directory object and the right-most value as being the directory root point.

Thus, a DN might be

uid=bjensen, ou=people, o=airius.com

This DN represents the entry named bjensen in the subdirectory named people in the directory named airius.com.

The DN's left-most value is known as the Relative Distinguished Name (RDN). Following this value are subsequent attributes that represent a branch point above the entry. The final, or right-most, attribute represents the conceptual root point of the directory tree.

Suffix

A Directory Server's suffix value identifies the directory tree maintained by the server. That is, a suffix is always equal to the directory tree's root entry (see the example below). Suffixes are represented in DN format. Every Netscape Directory Server has multiple suffixes defined for it. Only one, however, is of general importance, and this is called the primary suffix. The primary suffix represents the directory tree under which you are storing directory information of interest to your enterprise. You can have more than one primary suffix defined for your server. That is, you can have more than one directory tree managed by your server.

For example, a Directory Server that contains an entry named

uid=bjensen, ou=people, o=airius.com

o=airius.com

uid=bjensen, ou=people, dc=airius, dc=com

dc=airius, dc=com

Root Entry

The root entry is the first, or top-most, entry in your directory tree. The root entry must have a DN that is identical to a suffix defined for your directory. Thus, if you have the suffix o=airius.com then the root entry (that is, the first entry) in your directory tree must have the distinguished name of o=airius.com

Similarly, if the suffix contains multiple attributes (dc=airius, dc=com), then the DN of the first entry in the directory tree must be dc=airius, dc=com.

Directory Manager

The Directory Manager is the special entry to which access control does not apply. Think of the Directory Manager as your directory's superuser. In previous versions of the Directory Server, the Directory Manager was known as the root DN, and this term is still used in the Directory Server's configuration file, as well as in some of it's user interface screens.

By default, the Directory Manager uses no suffix, and it is simply a common name attribute-data pair:

cn=Directory Manager

All information regarding the Directory Manager and its password is stored in the Directory Server's configuration file (slapd.conf). The Directory Manager's password can be stored in clear text or in encrypted form (by default it is encrypted).

Configuration of a Directory Manager for your server is optional, but it is strongly recommended because without it the creation of directory entries and the initial setting of access control privileges is difficult. You can configure your Directory Manager when you first install your Directory Server instance. You can also create a Directory Manager, change your Directory Manager, or delete your Directory Manager after you have installed your server. For more information on managing the Directory Manager, see the Netscape Directory Server Administrator's Guide.

Base Distinguished Name

The Base Distinguished Name, or base DN, is the entry in your directory from which searches will occur. This search point is determined by settings created on each individual LDAP client using your directory.

The base DN is also often referred to as the search base. In addition, Netscape Communicator's preference settings for directories refers to this as the search root.

For example, if you specify a base DN of ou=people, o=airius.com, then the search operation will examine only the ou=people subtree in the o=airius.com directory tree.

Every LDAP search request must specify a base DN. Most often you will configure your LDAP client such that it uses your directory's root entry for the base DN. In this way, your LDAP client will always search the entire directory tree when performing searches.

Secure Sockets Layer

You can set up your Directory Server to use encryption for server communications. Encryption is most important to directory services running over public networks such as the Internet.

Directory server encryption is performed using the Secure Sockets Layer, or SSL. Encrypted LDAP communications are referred to as LDAPS connections.

SSL is used throughout the Netscape Server Family to perform other security activities such as message integrity checks, digital signatures, and mutual authentication between servers as well as between servers and clients.

In order for your server to use LDAPS, you must configure a security database for the server, and then turn on SSL in the server. Your server is capable of simultaneously handling both LDAP and LDAPS communications.

For more information on SSL, see Managing Servers with Netscape Console. For more information on LDAPS, see the Netscape Directory Server Administrator's Guide.