Previous     Contents     Index     DocHome     Next     
iPlanet Directory Server 5.1 Deployment Guide



Chapter 1   Introduction to Directory Server


iPlanet Directory Server provides a centralized directory service for your intranet, network, and extranet information. Directory Server integrates with existing systems and acts as a centralized repository for the consolidation of employee, customer, supplier, and partner information. You can extend Directory Server to manage user profiles and preferences, as well as extranet user authentication.

This chapter describes the basic ideas you need to understand before designing your directory. It includes the following sections:



What is a Directory Service?

The term directory service means the collection of software, hardware, and processes that store information about your enterprise, subscribers, or both and make that information available to users. A directory service consists of at least one instance of Directory Server and one or more directory client programs. Client programs can access names, phone numbers, addresses, and other data stored in the directory.

One common directory service is a Domain Name System (DNS) server. A DNS server maps a computer host name to an IP address. Thus, all of the computing resources (hosts) become clients of the DNS server. The mapping of host names allows users of your computing resources to easily locate computers on your network by remembering host names rather than numerical IP addresses.

However, the DNS server stores only two types of information: names and IP addresses. A true directory service stores virtually unlimited types of information.

iPlanet Directory Server stores all of your information in a single, network-accessible repository. The following are a few examples of the kinds of information you might store in a directory:

  • Physical device information, such as data about the printers in your organization (where they reside, whether they are color or black and white, their manufacturer, date of purchase, and serial number)

  • Public employee information, such as name, email address, and department

  • Private employee information, such as salary, government identification numbers, home addresses, phone numbers, and pay grade

  • Contract or account information, such as the name of a client, final delivery date, bidding information, contract numbers, and project dates

iPlanet Directory Server serves the needs of a wide variety of applications. It also provides a standard protocol and application programming interfaces (APIs) to access the information it contains.

The following sections describe global directory services and the Lightweight Directory Access Protocol (LDAP).


About Global Directory Services

iPlanet Directory Server provides global directory services, meaning it provides information to a wide variety of applications. Until recently, many applications came bundled with their own proprietary databases. While a proprietary database can be convenient if you use only one application, multiple databases become an administrative burden if the databases manage the same information.

For example, suppose your network supports three different proprietary email systems, each system with its own proprietary directory service. If users change their passwords in one directory, the changes are not automatically replicated in the others. Managing multiple instances of the same information results in increased hardware and personnel costs, a problem referred to as the n + 1 directory problem.

A global directory service solves the n+1 directory problem by providing a single, centralized repository of directory information that any application can access. However, giving a wide variety of applications access to the directory requires a network-based means of communicating between the applications and the directory. iPlanet Directory Server uses LDAP (Lightweight Directory Access Protocol) to give applications access to its global directory service.


About LDAP

LDAP provides a common language that client applications and servers use to communicate with one another. LDAP is a "lightweight" version of the Directory Access Protocol (DAP) used by the ISO X.500 standard. DAP gives any application access to the directory via an extensible and robust information framework, but at an expensive administrative cost. DAP uses a communications layer that is not the Internet standard TCP/IP protocol and has complicated directory-naming conventions.

LDAP preserves the best features of DAP while reducing administrative costs. LDAP uses an open directory access protocol running over TCP/IP and uses simplified encoding methods. It retains the X.500 standard data model and can support millions of entries for a modest investment in hardware and network infrastructure.



Introduction to iPlanet Directory Server


iPlanet Directory Server includes the directory itself, the server-side software that implements the LDAP protocol, and a graphical user interface that allows end-users to search and change entries in the directory. Other LDAP clients are also available, including the directory managers in the iPlanet Console and the Address Book feature in Netscape Communicator 4.x. In addition, you can purchase other LDAP client programs or write your own using the LDAP client SDK included with the iPlanet Directory Server product.

Without adding other LDAP client programs, Directory Server can provide the foundation for your intranet or extranet. Every iPlanet server uses the directory as a central repository for shared server information, such as employee, customer, supplier, and partner data.

You can use Directory Server to manage extranet 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.

When you install Directory Server, the following components are installed on your machine:

This guide talks about the core Directory Server and the plug-ins it uses for doing its work. The next sections describe Directory Server in more detail. The topics discussed are:


Overview of Directory Server Architecture

At installation, Directory Server contains the following:

  • A server front-end responsible for network communications

  • Plug-ins for server functions, such as access control and replication

  • A basic directory tree containing server-related data.

The following sections describe each component of the directory in more detail.


Overview of the Server Front-End

The server front-end of Directory Server manages communications with directory client programs. Directory Server functions as a daemon on UNIX systems and as a service on Windows NT and Windows 2000. Multiple client programs can speak to the server in LDAP. They can communicate using LDAP over TCP/IP. The connection can also be protected 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. In the future, when DNS security is present, TLS used in conjunction with secured DNS will provide confirmation to client applications that they are binding to the correct server. If clients have been issued certificates, TLS can be used by iPlanet Directory Server to confirm that the client has the right to access the server. TLS and its predecessor SSL are used throughout iPlanet Directory Server products to perform other security activities such as message integrity checks, digital signatures, and mutual authentication between servers.

Multiple clients can bind to the server at the same time over the same network because the Directory Server is a multi-threaded application. 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 places around the network.


Server Plug-ins Overview

Directory Server relies on plug-ins. A plug-in is a way to add functionality to the core server. For example, a database is a plug-in.

A plug-in can be disabled. When disabled, the plug-in's configuration information remains in the directory but its function is not used by the server. Depending upon what you want your directory to do, you can choose to enable any of the plug-ins provided with Directory Server.

iPlanet Professional Services can write custom plug-ins for your Directory Server deployment. Contact iPlanet Professional Services for more information.


Overview of the Basic Directory Tree

The directory tree, also known as a directory information tree or 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. At installation, Directory Server creates a default directory tree.

The default directory tree appears as follows:



The root of the tree is called the root suffix. For information about naming the root suffix, refer to "Choosing a Suffix".

At installation, the directory contains up to four subtrees under your root suffix:

  • cn=config

    This subtree contains information about the server's internal configuration.

  • o=NetscapeRoot

    This subtree contains the configuration information of other iPlanet servers, such as iPlanet Administration Server. The Administration Server takes care of authentication and all actions that cannot be performed through LDAP (such as starting or stopping).

  • o=userRoot

    During installation, a user database is created by default. Its default name is o=userRoot. You can choose to populate it at installation time, or populate later.


    Note When you install another instance of Directory Server, you can specify that it does not contain the o=NetscapeRoot information, that it uses the configuration directory (or the o=NetscapeRoot subtree) present on another server. See the iPlanet Directory Server Installation Guide for more information about deciding upon the location of your configuration directory.


You can build on the default directory tree to add any data relevant to your directory installation. An example of a directory tree for siroe.com Corporation follows:



For more information about directory trees, refer to Chapter 4 "Designing the Directory Tree."


Directory Server Data Storage

Your directory data is stored in an LDBM database. The LDBM database is implemented as a plug-in that is automatically installed with the directory and is enabled by default.

The database is the basic unit of storage, performance, replication, and indexing. You can do operations like importing, exporting, backing up, restoring, and indexing on the database.

By default, Directory Server uses a single database to contain the directory tree. This database can manage millions of entries. The default database supports advanced methods of backing up and restoring your data, so that your data is not at risk.

You can choose to use multiple databases to support your Directory Server. You can distribute your data across the databases, allowing the server to hold more data than can be stored in a single database.

The following sections describe how a directory database stores data.


About Directory Entries

LDIF (LDAP Data Interchange Format) is a standard text-based format for describing directory entries. An entry is a group of lines in the LDIF file that contains information about an object, such as a person in your organization or a printer on your network. Information about the entry is represented in the LDIF file by a set of attributes and their values. Each entry has an object class attribute that specifies the kind of object the entry describes and defines the set of additional attributes it contains. Each attribute describes a particular trait of an entry.

For example, an entry might have the object class organizationalPerson, indicating that the entry represents a person within a particular organization. This object class allows the givenname and telephoneNumber attributes. The values assigned to these attributes give the name and phone number of the person represented by the entry.

iPlanet Directory Server also uses read-only attributes that are calculated by the server. These attributes are called operational attributes. There are also some operational attributes that can be set by the administrator, for access control and other server functions.

Entries are stored in a hierarchical structure in the directory tree. In LDAP, you can query an entry and request all entries below it in the directory tree. This subtree is called the base distinguished name, or base DN. For example, if you make an LDAP search request specifying a base DN of ou=people, dc=siroe,dc=com, then the search operation examines only the ou=people subtree in the dc=siroe,dc=com directory tree.

However, all entries are not automatically returned in response to an LDAP search. Entries of the ldapsubentry object class are not returned in response to normal search requests. An ldapsubentry entry represents an administrative object, for example the entries that are used internally by Directory Server to define a role or a class of service. To receive these entries, clients need to search specifically for entries of the ldapsubentry object class.

For more information about roles, see "Managed, Filtered, and Nested Roles". For more information about class of service, see "Class of Service".


Distributing Directory Data

When you store various parts of your tree in separate databases, your directory can process client requests in parallel, improving performance. You can also store your databases on different machines, to further improve performance.

To connect your distributed data, you can create a special entry in a subtree of your directory. All LDAP operations attempted below this entry are sent to a remote machine where the entry is actually stored. This method is called chaining.

Chaining is implemented in the server as a plug-in. The plug-in is enabled by default. Using this plug-in, you create database links, special entries that point to data stored remotely. When a client application requests data from a database link, the database link retrieves the data from the remote database and returns it to the client.



Directory Design Overview


The previous sections described directory services in general and the iPlanet Directory Server in particular. Now it is time to consider the design of your own directory service.

Planning your directory service before actual deployment is the most important task to ensure the success of your directory. During your directory design you will gather data about your directory requirements, such as environment and data sources, your users, and the applications that will use your directory. With this data, you can design a directory service that meets your needs.

However, keep in mind that the flexibility of iPlanet Directory Server allows you to rework your design to meet unexpected or changing requirements, even after you deploy Directory Server.


Design Process Outline

The remainder of this guide divides the design process into six steps:

  • How to Plan Your Directory Data.

    Your directory will contain data, such as user names, telephone numbers, and group details. Chapter 2 "How to Plan Your Directory Data," helps you analyze the various sources of data in your organization and understand their relationship with one another. It describes the types of data you might store in your directory, and other tasks you need to perform to design the contents of your Directory Server.

  • How to Design the Schema.

    Your directory is designed to support one or more directory-enabled applications. These applications have requirements of the data you store in your directory, such as format requirements. Your directory schema determines the characteristics of the data stored in your directory. Chapter 3, "How to Design the Schema," introduces the standard schema shipped with iPlanet Directory Server, describes how to customize the schema, and provides tips for maintaining consistent schema.

  • Designing the Directory Tree.

    Once you decide what data your directory contains, you need to organize and reference that data. This is the purpose of the directory tree. In Chapter 4 "Designing the Directory Tree," the directory tree is introduced and you are guided through the design of your data hierarchy. Sample directory tree designs are also provided.

  • Designing the Directory Topology.

    Topology design involves determining how you divide your directory tree among multiple physical Directory Servers and how these servers communicate with one another. Chapter 5 "Designing the Directory Topology," describes the general principles behind topology design, discusses using multiple databases, describes the mechanisms available for linking your distributed data together, and explains how the directory itself keeps track of distributed data.

  • Designing the Replication Process.

    With replication, multiple Directory Servers maintain the same directory data to increase performance and provide fault tolerance. Chapter 6, "Designing the Replication Process," describes how replication works, what kinds of data you can replicate, common replication scenarios, and tips for building a highly available directory service.

  • Designing a Secure Directory.

    Finally, you need to plan how to protect the data in the directory and design the other aspects of your service to meet the security requirements of your users and applications. Chapter 7, "Designing a Secure Directory," describes common security threats, provides an overview of security methods, discusses the steps in analyzing your security needs, and provides tips for designing access controls and protecting the integrity of your directory data.


Deploying Your Directory

After you have designed your directory service, you start the deployment phase. The deployment phase consists of the following steps:


Piloting Your Directory

The first step of the deployment phase is installing a server instance as a pilot and testing whether your service can handle your user load. If the service is not adequate as it is, adjust your design and pilot it again. Adjust your pilot design until you have a robust service you can confidently introduce to your enterprise.

For a comprehensive overview of creating and implementing a directory pilot, refer to Understanding and Deploying LDAP Directory Services (T. Howes, M. Smith, G. Good, Macmillan Technical Publishing, 1999).


Putting Your Directory Into Production

Once you have piloted and tuned the service, you need to develop and execute a plan for taking the directory service from a pilot to production. Create a production plan that includes the following:

  • An estimate of the resources you need

  • A list of the tasks you must perform before installing servers

  • A schedule of what needs to be accomplished and when

  • A set of criteria for measuring the success of your deployment

For information on installing your directory service, refer to the iPlanet Directory Server Installation Guide. For information on administering and maintaining your directory, refer to the iPlanet Directory Server Administrator's Guide.



Other General Directory Resources


For more information about directories, LDAP, and LDIF, take a look at the following:


Previous     Contents     Index     DocHome     Next     
Copyright © 2001 Sun Microsystems, Inc. Some preexisting portions Copyright © 2001 Netscape Communications Corp. All rights reserved.

Last Updated October 29, 2001