Lightweight Directory Access Protocol (LDAP)
LDAP is the latest name-lookup service to be added to Solaris. It can be used in conjunction with or in place of NIS+ or DNS. Specifically, LDAP is a directory service. A directory service is like a database, but it contains more descriptive, attribute-based information. The information in a directory is generally read, not written.
LDAP is used as a resource locator, but it is practical only in read-intensive environments in which you do not need frequent updates. LDAP can be used to store the same information that is stored in NIS or NIS+. Use LDAP as a resource locator for an online phone directory to eliminate the need for a printed phone directory. This application is mainly read-intensive, but authorized users can update the contents to maintain its accuracy.
LDAP provides a hierarchical structure that more closely resembles the internal structure of an organization and can access multiple domains, similar to DNS or NIS+. NIS provides only a flat structure and is accessible by only one domain. In LDAP, directory entries are arranged in a hierarchical treelike structure that reflects political, geographic, or organizational boundaries. Entries representing countries appear at the top of the tree. Below them are entries representing states or national organizations. Below them might be entries representing people, organizational units, printers, documents, or just about anything else you can think of.
LDAP has provisions for adding and deleting an entry from the directory, changing an existing entry, and changing the name of an entry. Most of the time, though, LDAP is used to search for information in the directory.
Note
LDAP is a protocol that email programs can use to look up contact information from a server. For instance, every email program has a personal address book, but how do you look up an address for someone who has never sent you email? Client programs can ask LDAP servers to look up entries in a variety of ways. The LDAP search operation allows some portion of the directory to be searched for entries that match some criteria specified by a search filter.
LDAP servers index all the data in their entries, and “filters” may be used to select just the person or group you want and return just the information you want to see. Information can be requested from each entry that matches the criteria. For example, here’s an LDAP search translated into plain English: “Search people located in Hudsonville whose name contains ‘Bill’ and that have an email address. Return their full name and email address.”
Perhaps you want to search the entire directory subtree below the University of Michigan for people with the name Bill Calkins, retrieving the email address of each entry found. LDAP lets you do this easily. Or, you might want to search the entries directly below the U.S. entry for organizations with the string “Pyramid” in their names and that have a fax number. LDAP lets you do this.
Some directory services provide no protection, allowing anyone to see the information. LDAP provides a method for a client to authenticate, or prove its identity to a directory server, paving the way for rich access control to protect the information the server contains.
LDAP was designed at the University of Michigan to adapt a complex enterprise directory system, called X.500, to the modern Internet. A directory server runs on a host computer on the Internet, and various client programs that understand the protocol can log into the server and look up entries. X.500 is too complex to support on desktops and over the Internet, so LDAP was created to provide this service to general users.
iPlanet Directory Server
iPlanet Directory Server is a Sun product that provides a centralized directory service for your network and is used to manage an enterprise-wide directory of information, including the following:
Physical device information, such as data about the printers in your organization. This could include location information, support of color or duplexing, the manufacturer and serial number, company asset tag information, and so on.
Public employee information, such as name, phone number, email address, and department.
Logins and passwords.
Private employee information, such as salary, employee identification numbers, phone numbers, emergency contact information, and pay grade.
Customer information, such as the name of a client, bidding information, contract numbers, and project dates.
iPlanet Directory Server meets the needs of many applications. It provides a standard protocol and a common interface (API) that client applications and servers need to communicate with each another.
As I’ve described, iPlanet Directory Server provides a hierarchical name space that can be used to manage anything that has previously been managed by the NIS and NIS+ name services. The advantages of the iPlanet Directory Server over NIS and NIS+ are listed here:
It gives you the capability to consolidate information by replacing application-specific databases. It also reduces the number of distinct databases to be managed.
It allows for more frequent data synchronization between masters and replicas.
It is compatible with multiple platforms and vendors.
Because iPlanet Directory Server is platform independent, it very likely will eventually replace NIS and NIS+, providing all the functionality once provided by these name services.
The iPlanet Directory Server runs as the ns-slapd process on your directory server. The server manages the directory databases and responds to all client requests. Each host in the domain that uses resources from the LDAP server is referred to as an LDAP client.
Setting Up the LDAP Client
It’s not within the scope of this chapter to describe how to set up an LDAP server; this requires an in-depth working knowledge of LDAP. For background information on LDAP and iPlanet Directory Server, refer to the iPlanet Directory Server Deployment Guide available at www.docs.sun.com.
It’s assumed that the LDAP server has already been configured as a naming service with the appropriate client profiles in place. The scope of this chapter is to describe how to set up the LDAP client.
Before setting up the LDAP client, a few things must already be in place:
The client’s domain name must be served by the LDAP server.
The nsswitch.conf file must point to LDAP for the required services.
At least one server for which a client is configured must be up and running.
The ldapclient utility is used to set up LDAP client. ldapclient assumes that the server has already been configured with the appropriate client profiles. The LDAP client profile consists of configuration information that the client uses to access the LDAP information on the LDAP server. You must install and configure the LDAP server with the appropriate profiles before you can set up any clients.
To initialize a client, log in as root.
Run the ldapclient command as follows:
ldapclient init -a profileName=new -a domainName=east.example.com 192.168.0.0
The system responds with this:
System successfully configured