Chapter 31: Lightweight Directory Access Protocol (LDAP)

In this chapter, you will

• Gain an understanding of white pages, DAP, and LDAP services

• Review the installation and configuration of the LDAP server

• Learn how to support LDAP clients

• Discover how to use directory services effectively in an organization

LDAP is a white pages type of service, which is similar to the older X.500 standard for managing organization-wide directory information, for which it originally acted as a front end. X.500 was based on the heavyweight Directory Access Protocol (DAP), while LDAP, as a lightweight protocol, sits directly on top of TCP/IP. Operations on LDAP servers like iDS are of two kinds: data management operations, where records are inserted, updated, or deleted, and queries, where authentication and identification tokens are retrieved from the organization s database. In theory, the LDAP protocol allows for a lot of different types of data about individuals and groups to be stored, including sounds, images, and text.

In Solaris 8, only an LDAP client was supplied with the operating environment release, making it less attractive to use than NIS/NIS+ because a separate LDAP server had to be purchased and installed. However, Solaris 9 has integrated the iPlanet Directory Server (iDS) into the core architecture, meaning that LDAP servers and clients can be installed and configured directly after and during installation, respectively. iDS, a key component of the iPlanet software suite, provides centralized authentication and authorization services for other iPlanet applications and for third-party applications. For example, access to the Internet mediated through the iPlanet Proxy Server can only be gained by being an attribute of a group defined within the local iDS database, demonstrating the key role that iDS plays in supporting enterprise applications. Alternatively, access to scheduling and event notification facilities through the iPlanet Calendar Server can only be provided to users who are authenticated through the iDS database.

Tip  

Many Solaris applications can use LDAP for authentication and authorization.

iDS does not use a proprietary protocol for storing user and group data or for communicating with clients; instead, iDS uses the LDAP standard for authenticating users. This is an open standard, meaning that a Solaris-based LDAP server can authenticate some Microsoft Windows clients. In addition, it means that iDS can act as a drop-in replacement for any other LDAP-compliant server, enabling you to standardize directory services across a single platform. Alternatively, multiple server types from different vendors can be combined to form an integrated solution. For example, you might choose to use iDS in mission-critical applications because of its clustering and high-availability features, which might be overkill in other situations. It is also possible to use the LDAP client software supplied with Solaris to connect to an LDAP server running on a different platform.

Two of the key benefits in switching from NIS/NIS+ are the ease of replication and the assurance of high availability. While NIS/NIS+ architecture is based on the idea of a primary server backed up by some slaves, LDAP servers can be replicated across subnets and domains to servers known as replicas, increasing the number of servers available for authoritative lookups and reducing the burden on any one server. In addition, updates occur rapidly between LDAP servers, rather than relying on uploads of all data between primary and slave servers in a NIS/NIS+ architecture.

Although LDAP has many features (and the iDS implementation implements all of the most important operations defined in the protocol), LDAP has a number of limitations. It does not have an interface defined to store data in a relational database, nor does it store data internally in a relational way. Although queries can be performed on the directory, these are not executed by using a query language (like SQL). LDAP is better designed for a reference data environment, where the types of lookups are well defined and data updates are infrequent.

However, its power lies in the flexibility to store and manage names and data in a flexible way. While there are predefined schema elements, such as users and organizations, other elements can be added where necessary. In addition, developers can write client programs that can easily access the directory and retrieve authoritative data.

Tip  

Since most networked applications perform some kind of authentication, a single, centralized source of authentication data can be accessed, reducing administrative overhead.

In this chapter we examine how to configure LDAP servers and configure a wide range of client services.

Exercise 31-1 LDAP Review     Go to www.sun.com , review the Sun ONE architecture, and see where LDAP fits into the picture.