| Directories are repositories of names. Names can be anything from a username to a hostname to a domain name , and are essential for navigating loosely structured data like the Internet. In Chapter 17, we spoke about a directory we all know and love: the Domain Name System (DNS). DNS works great, but it requires users to know the domain name they want. Applications like email and network management can benefit from more natural directory entries that include, for instance, people's names, type of service, or geographic location. This is particularly true on the global Internet, where the address space is growing exponentially; but it's increasingly true on wide-area intranets as well. This is essentially the problem solved in the old days with products such as Yellow Pages, a.k.a. NIS. There have been attempts at supplying directories as an integral part of the operating system with products such as Novell's NDS. Being proprietary, NDS was never going to work in open arenas such as UNIX and the Internet. In open networking, these capabilities are provided for in an international standard called X.500. Adoption of X.500, which has been around since 1988, has been slow because of its complexity and the practical constraint that its client half, Directory Access Protocol (DAP), was too big and cumbersome to run on most machines of the day. What we needed was the capabilities of X.500 but without all its baggage . Then, a couple of guys from the University of Michigan had a look at X.500 and decided it was a good starting point; they just needed to make it more efficient and sleeker . LDAP was born. Lightweight Directory Access Protocol (LDAP) is an Internet standard produced by the Internet Engineering Task Force (IETF). W. Yeong, T. Howes, and S. Kille at the University of Michigan wrote the original LDAP RFC. An excellent introduction to LDAP was written by Tim Howes and Mark Smith and is available at http://www.isoc.org/HMP/PAPER/173/html/paper.html. The protocol was designed to provide access to the directory while reducing the resource requirements of the Directory Access Protocol (DAP). The key feature of LDAP was that the protocol ran directly over TCP or other transports without requiring the overhead of session/presentation layer. LDAP providers support the most popular methods of authentication, including password based, Secure Socket Layer (SSL), and Kerberos. LDAP support of the Simple Authentication and Security Layer (SASL) allows for additional authentication methods to be negotiated. The following RFCs provide detailed information about the LDAPv3 protocol and other LDAP- related standards: -
Lightweight Directory Access Protocol v3 (RFC 2251) -
An Approach for Using LDAP as a Network Information Service (RFC 2307) -
A Summary of the X.500(96) User schema for use with LDAPv3 (RFC 2256) -
LDAPv3 Attribute Syntax Definitions (RFC 2252) -
UTF-8 String Representation of Distinguished Names (RFC 2253) -
The String Representation of LDAP Search Filters (RFC 2254) -
The LDAP URL Format (RFC 2255) -
Simple Authentication and Security Layer (RFC 2222) -
SSL 3.0 specification LDAP, or should we say Lightweight DAP, is also known as X.500 Lite; the protocol enables corporate directory entries to be arranged in a hierarchical structure that reflects geographic and organizational boundaries. Using LDAP, companies can map their corporate directories to actual business processes, rather than to arbitrary codes. The acceptance of Lightweight Directory Access Protocol technology has progressed at a rapid pace. Many enterprises have already deployed LDAP directories , primarily for messaging and security products. As more applications are directory enabled, important tasks such as administration, authentication, and authorization are being consolidated and centralized. Integrating important operating systems into the directory greatly enhances the value of this consolidation. Most UNIX vendors have some directory enablement, but little real integration with LDAP. I am sure that this situation will change in the not-too- distant future. In June 2000, HP entered the LDAP arena with a number of new products on HP-UX 11.0 that provide a full range of directory integration. We can choose the level of integration that meets our needs, or we may migrate our environments one level at a time: -
YPLDAP is a protocol gateway that allows UNIX configuration data to be migrated to an LDAP directory, and accessed via existing client software (NIS). -
NSS_LDAP accesses configuration data via native LDAP (the name service switch file /etc/nsswitch.conf ). -
PAM_LDAP authenticates HP-UX users to an LDAP directory (the /etc/pam.conf file to integrate with the login process). -
LDAP Access Profiles provide the ability to customize NSS_LDAP and PAM_LDAP directory access to enable integration and data sharing with other applications and platforms using LDAP. LDAP directories are arranged like a UNIX filesystem (an inverted tree). Below the topmost root node, country information appears, followed by entries for companies, states, or national organizations. Next come entries for organizational units , such as branch offices and departments. Finally, we locate individuals , which in X.500 and LDAP includes people, shared resources such as printers, and documents. An LDAP directory server makes it possible for a corporate user to find the information resources they need anywhere within the enterprise network. The namespace looks very much like the namespace of DNS, but names are referenced in a different format. For example, we could have a top-level organization called maabof.com (our DNS domain name). We would reference this entry as o=maabof.com . Organization units are referenced below our organization . Some administrators have been known to store their UNIX-type information in an organizational unit called unix . We could reference this using the name ou=unix , o=maabof.com . Below that, we would have People ou=People , ou=unix , o=maabof.com . Eventually, we get to individual entries that have a common name cn=Alice referred to as the Relative Distinguished Name . Entries are named by one of their attributes, e.g., uid . Entries themselves are typed by using an attribute known as objectClass ; for example, the objectClass for Alice could be objectClass = person . A fully qualified entry is known by its Distinguished Name and includes the entry used to identify it; for example, the DN for Alice could be dn: uid=Alice,ou=People,ou=unix,o=maabof.com (Figure 21-1). Figure 21-1. Example LDAP namespace. 
What we need is a piece of software to house our directory. Commonly, that software will be Netscape Directory Services on UNIX (or it could alternately be the iplanet software). Windows 2000 uses Active Directory Services and could be used to store our UNIX usernames and passwords. The directory acts like a database. Like any other database, our directory has a schema associated with it. In a POSIX arena like HP-UX, we need a mechanism to ensure that the directory schema accommodates POSIX objects and attributes. This has been taken care of by RFC 2307 (http://www.ietf.org/rfc/rfc2307.txt), which provides a standard way to represent POSIX naming information in an LDAP directory. We need to ensure that our Directory Services product adheres to this schema . Netscape Directory Services 4.X has the RFC 2307 schema already installed. We next need to consider which LDAP Integration products we will use on HP-UX. |
