test

LDAP Setup and Configuration Guide

Chapter 1 Overview

The LDAP Setup and Configuration guide describes how to set up an iPlanet LDAP directory server and how to set up a Solaris client to support the naming service.

Naming Service

Naming services store information in a central place that users, workstations, and applications must have to communicate across the networks. This information includes:

Without a central name service, each workstation would have to maintain its own copy of this information which makes it extremely expensive to administer large networks. Name service information can be stored in files, database tables and so on.

Solaris Name Services

The Solaris operating environment provides the following name services:

For the detailed explanation of first four name services, refer to the Solaris Naming Administration Guide.

Most modern networks use a combination of two or more of these services that are coordinated by the name service switch, also known as the switch. The switch controls how a client workstation or application obtains network information. It determines which naming services an application uses to obtain naming information. For more information on Solaris switch, see nsswitch.conf(4).

LDAP Model

LDAP is the emerging industry standard protocol for accessing directory servers. It is a lightweight protocol. It is efficient, straight forward, and easy to implement, while still being highly functional. It uses a simplified set of system-independent encoding methods and runs directly on top of TCP/IP.

LDAP directories provide a way to name, manage, and access collections of directory entries. A directory entry is composed of attributes that have a type and one or more values. The syntax for each attribute defines the values allowed (such as ASCII characters or a jpeg photograph) and how those values are interpreted during a directory operation (such as whether a search or compare is case sensitive) .

Directory entries are organized into a tree structure, based on geographic (country), organizational (company) boundaries, or domains (dc).

Entries are named according to their position in this tree structure by a distinguished name (DN). Each component of the distinguished name is called a relative distinguished name (RDN). An RDN is composed of one or more attributes from the entry. (See RFC 2253 for a formal definition of a distinguished name.)

The hierarchy of the directory tree structure is analogous to that of the UNIX file system. An RDN is analogous to the name of a file, and the DN is analogous to the absolute pathname to the file. As in the UNIX file system, sibling directory entries must have unique RDNs. However, in the directory tree, both leaf nodes and nonleaf nodes can contain content or attributes.

Like the DNS namespace, LDAP directory entries are accessed in a “little-endian” manner. This means that LDAP names start with the least significant component and proceed to the most significant, that just below root. The DN is constructed by concatenating the sequence of RDNs up to the root of the tree. For example, if the person named Joe Qwerty works for the company named Ultra Keyboards in the United States, the commonName (CN) attribute for the person Joe Qwerty contains the value “Joseph Qwerty”. The DN contains “cn=Joseph Qwerty, o=Ultra Keyboards, c=US”.

Why LDAP as a Naming Service?

LDAP has the potential to replace existing application-specific directories and consolidate information. This means that changes made on an LDAP server will take effect for every directory-enabled application that uses this information. Imagine adding a variety of information about a new user through a single interface only once, and immediately the user has a Unix account, a mail address and aliases, membership in departmental mailing lists, access to a restricted Web server, and inclusion in job-specific restricted newsgroups. The user is also instantly included in the company's phone list, mail address book, and meeting calendar system. When a user leaves, access can be disabled for all of these services with just a single operation.

A directory is distinguished from a general-purpose database by the usage pattern. A directory contains information that is often searched but rarely modified. Host names or user names, for example, are assigned once and then looked up thousands of times. LDAP servers are tuned for this type of usage, whereas relational databases are much more geared toward maintaining data that is constantly changing.

A directory can be replicated to protect from unfortunate situations like equipment failure by making the directory data available on multiple servers, known as replica servers. Replicas also improve performance by making more copies of directory data available and by placing the data close to the users and applications that use them.

Reducing load on the authoritative server is not the only reason for using replica servers. Many Unix networks use Network Information Service (NIS), also known as YP, which uses slave servers on each subnet. As with NIS, putting replicas on subnets can avoid network traffic through routers and reduce latency. However, unlike NIS, the LDAP synchronization scheme features incremental updates that can be pushed immediately to the replicas rather than periodically transferring all of the data.

In order for authoritative information to be maintained, access control needs to be imposed for privileges to read, write, search, or compare. Access control can be done on a subtree, entry, or attribute type and granted to individuals, groups, or "self" (which allows an authenticated user to access his or her own entry). This scheme provides a great deal of flexibility. For example, you may want to only allow people in a personnel department to change the title or manager attributes, allow administrative assistants to change office location and pager number information for just their department, and allow individuals to modify their own home phone number, car license plate, and so on. For more information, check the iPlanet directory server documents.

Let's look at Unix login information as an example. Once attributes for users are stored in a directory server, you can synchronize user names and passwords for multiple operating system platforms when updated through Directory Server interface. This not only simplifies the change for users but can reduce the chance of having infrequently used accounts with forgotten passwords.

LDAP as a Naming Service in the Solaris Operating Environment

In Solaris, like NIS and NIS+, LDAP can also be used by the naming service switch to allow Solaris clients to obtain naming information.

The predominant protocol-independent interfaces to naming services within Solaris are the standard getXbyY APIs. An application using getXbyY() calls (e.g., gethostbyname(3NSL)) goes through the naming service switch which in turn calls the appropriate source protocol. In the case of LDAP, it calls LDAP APIs to retrieve information from a LDAP server. See nsswitch.conf(4) for more information about the naming service switch.

Figure 1–1 shows an overview of the relationship of the name services, the naming service switch, and the various parts of the LDAP implementation.

Figure 1–1 Architecture Overview

Graphic

In addition to all the features of LDAP previously mentioned, the Solaris client configuration and maintenance is greatly simplified by storing client profiles in the directory. Each client runs a daemon that is responsible for refreshing the configuration by downloading the latest profile from the directory. Once a change is required in client configuration (such as the addition of new LDAP servers, changes in security model, and so on), the system administration merely modifies the appropriate profile(s), and the clients will get the latest configuration automatically. See ldap_cachemgr(1M) for more information.

LDAP Operations

LDAP defines nine operation in three areas: