[Contents] [Previous] [Next] [Index]

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 SuiteSpot 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

 The enterprise is often defined to mean all aspects of your computing environment -- from the mainframe (if applicable) to the server (Unix or NT) to the desktop level.

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.

What Is a Directory Service?

A directory service is a collection of software that you use to store information about your enterprise. Sometimes, but not always, directory services are based on a client-server architecture. Therefore, a directory service generally consists of at least one directory server and one or more directory clients.

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:

Ultimately a robust, scalable directory service allows you to store all of your enterprise's information in a single, network-accessible repository.

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) could 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 is 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 is the X.500 ISO standard. 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.

The Netscape Directory Server

The Netscape Directory Server 3.0 supports LDAP versions 2 and 3. Each directory server instance is capable of supporting millions of entries and hundreds of queries per second. Further, through the use of replication and referrals, the directory server can be scaled to support even the largest of enterprises, up to and including the multinational corporation.

Without modification, the directory server can provide the foundation for your intranet or extranet. Every Netscape SuiteSpot 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 Users and Groups area in the Netscape Administration Server and the addressbook feature in Netscape Communicator 4.0. 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). Note that 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.

Directory Server Concepts

You need to understand a few key concepts before you can deploy even a simple LDAP directory service. Understanding these concepts will save you a great deal of time when you install your Netscape Directory Server.

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:

Note that a similar term, Directory Information Tree (DIT), is often used to refer to an enterprise's directory tree. However, DIT 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 at least two 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
might have a suffix named

o=airius.com
However, suffixes do not have to be limited to a single component. In fact, it is very common for a suffix to contain at least two components. For example, the entry

uid=bjensen, ou=people, dc=airius, dc=com
might have a suffix named

dc=airius, dc=com
Note that your server will always have a second suffix defined for it that represent your server's machine data area. Your server may also have a change log suffix defined for it. For more information on the machine data area and the change log, see the Netscape Directory Server Administrator's Guide.

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.

Root Distinguished Name

The Root Distinguished Name, or root DN, is the special entry to which access control does not apply. Think of the root DN as your directory's superuser.

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

cn=Directory Manager
Note that the root DN is not required to have a corresponding entry in the directory. As a result, if you search your directory server for your root DN entry, you usually will not find it (unless you explicitly created a corresponding entry for the root DN). Also, unless you intend to create an actual directory entry that corresponds to your root DN, your root DN does not have to correspond to any of the suffixes managed by your server.

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

Configuration of a root DN 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 root DN when you first install your directory server instance. You can also create a root DN, change your root DN, or delete your root DN after you have installed your server. For more information on root DN management, 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.

Note that 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

When you install your directory server, you are given the option 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.

Note that SSL is used throughout SuiteSpot 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. Note that your server is capable of simultaneously handling both LDAP and LDAPS communications.

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

[Contents] [Previous] [Next] [Index]

Last Updated: 02/17/98 15:41:51

Copyright © 1997 Netscape Communications Corporation




Изменено 19-Mar-98 10:06
Copyright (С) 1999 Оптилинк