Is LDAP Your Directory Solution?

IBM, along with the rest of the industry, has recently provided support of a new Internet protocol called LDAP (Lightweight Directory Access Protocol) to help you access information in your directories.

Your computing environment has continued to change in recent years; going from a single computer to multiple computers, from a single vendor to multi-vendor, and from centralized to distributed applications. A network now connects these computers together and it seems your application data is everywhere. Sometimes you wish things were the way they use to be, data was all located on one system and accessible by all applications. The applications in your network just don't share the information efficiently and you're stuck with having to continue to update the same information in several of these directories (which continues to grow in number).

Lightweight Directory Access Protocol (LDAP), an Internet protocol for accessing directories, may help you with your directory problems. LDAP is an open industry standard that has evolved to meet the needs for accessing and updating information in directories. LDAP is gaining wide acceptance as the directory access method of the Internet and is therefore also becoming strategic within corporate intranets. It is supported by a growing number of software vendors and is being incorporated into a growing number of applications. IBM has already delivered LDAP support for i5/OS, AIX, OS/390, NT and Windows.

A directory is a listing of information about objects arranged in some order that gives details about each object. Common examples are a city telephone directory and a library card catalog. In computer terms, a directory is a specialized database, also called a data repository, that stores typed and ordered information about objects. Directories allow users or applications to find resources that have the characteristics needed for a particular task. For example, a directory of users can be used to look up a person's e-mail address or fax number. A directory could be searched to find a nearby PostScript color printer. Or a directory of application servers could be searched to find a server that can access customer billing information. Searching a directory is similar to looking up a name in the white or yellow pages of a telephone directory. If the name of a particular individual object is not known, the directory can be searched for a list of objects that meet a certain requirement. However, directories stored on a computer are much more flexible than the yellow pages of a telephone directory because they can usually be searched by specific criteria, not just by a predefined set of categories.

Although directories may of originally been used for databases of personal information, such as a telephone number or e-mail address, the number of directory applications has recently increased considerably. Directories are now being used to hold all of the information about a person and are being used for authenticating a user to network services. Systems management applications have recently started exploiting the directory for profile-based management of system resources, such as bandwidth utilization of a network.

In 1988, the CCITT (Consultative Committee on International Telephony and Telegraphy), created the X.500 standard, which became ISO 9594, Data Communications Network Directory, Recommendations X.500-X.521 in 1990, though it is still commonly referred to as X.500. X.500 organizes directory entries in a hierarchical name space capable of supporting large amounts of information and specifies that communication between the directory client and the directory server uses the directory access protocol (DAP). However, as an application layer protocol, the DAP requires the entire OSI protocol stack to operate. Supporting the OSI protocol stack requires more resources than available in many small environments.

Therefore, an interface to an X.500 directory server using a less resource-intensive or lightweight protocol was desired. LDAP was developed at the University of Michigan as a lightweight alternative to DAP (thus the name LDAP). LDAP requires the lighter weight and more popular TCP/IP protocol stack rather than the OSI protocol stack. LDAP also simplifies some X.500 operations and omits some esoteric features.

LDAP defines a communication protocol. That is, it defines the transport and format of messages used by a client to access data in an X.500-like directory. LDAP does not define the directory service itself. However, when referring to a directory that can be accessed using LDAP, the directory is usually called an LDAP directory. Therefore, LDAP directories can be implemented in many different ways. IBM implements cross platform LDAP directories using DB2 and Lotus Domino.

LDAP has developed into the industry standard for directory access for the following reasons:

• LDAP is easy to implement
• LDAP has good and appropriate functionality
• LDAP is well defined and nonproprietary
• LDAP is capable of extension
• LDAP can be used within the wide range of environments
• LDAP is independent of the 'server' directory' technology
• LDAP is readily available today on all computer platforms

Information in an LDAP directory is organized as a tree, called a Directory Information Tree (DIT). Information is stored in the directory as objects or directory entries. These objects are referenced using a distinguished name (DN), following the syntax defined by the X.500 standards. An example of an object's DN is: "cn=John Smith, ou=Executives, o=Deltawing, c=au".

Software servers supporting LDAP, referred to as LDAP servers, provide services that fall into one of the following categories.

• An LDAP server may provide LDAP access to existing directories, such as X.500 directories or Novell Directory Services (NDS). The LDAP server provides 'proxy' or 'gateway' services allowing LDAP as an alternative directory access protocol. Novell's LDAP server is an example of this since it provides LDAP access to existing NetWare directories.
• An LDAP server may provide LDAP access to existing (non-directory) databases of information. In this case, the LDAP server provides a "directory view" of this information to LDAP clients without converting or moving existing data into a directory. An example would be an LDAP server providing access to an Oracle database.
• An LDAP server may provide access to its own directory where the information is only available by LDAP. The LDAP server and its data repository are specialized to providing the directory services to LDAP users. An example would be the LDAP servers provided by IBM for IBM servers and NT.

Note than in all three of these cases, the directory supported by the LDAP server is considered an LDAP directory and is accessed by an LDAP client the same way.

An LDAP client is a software application that accesses an LDAP server using a TCP/IP connection. The client accesses the LDAP directory using an industry standard API, such as the LDAP C API, and does not need to know how the LDAP server stores the information. A client may log on anonymously to an LDAP server, thus seeing only 'public' information, or authenticate as a specific user in which case information to which that particular user is allowed access is also made visible.

LDAP, which has become the Internet standard for directory operations, is starting to replace the more familiar HTTP in some Internet applications. An Internet URL may specify the address of an LDAP server, instead of an HTTP server. When specifying an LDAP URL, parameters can be specified to perform searches of the directory. For example, using a web browser you can search a directory to display personal information by specifying:

Ldap://ldap_server/c=rochester,o=ibm??sub?(cn=John Smith)

Besides the X.500 based directory, the computing industry has implemented many different directories. Some directories are application specific, while other directories are associated with operating systems. A few years ago, 40 computer industry leaders announced their support of the directory access protocol called LDAP. Over night, LDAP became the solution the industry was looking for accessing the numerous directories in the network. LDAP became popular within the industry because it did not dictate how a directory was to implemented, but rather how it could be accessed. Besides the numerous standards documenting the directory protocol, standards for C and Java APIs exist allowing applications written on any major platform to access any directory support the LDAP protocol.

LDAP directories may be located on a single server or configured across multiple servers. LDAP servers can replicate information between servers, making information more accessible. Synchronization of LDAP directories with non-LDAP directories provides for a 'meta-directory' and a consistent method for all directory access. You can deploy applications that provide the synchronization, thus extending your LDAP directory to meet your specific needs. Below, we'll discuss extending the directory in more detail.

IBM is working with the standards committees to further the LDAP standards, allowing for additional exploitation of LDAP within the industry. Besides IBM, Netscape, Microsoft and Novell are also very active in the standards.

IBM is using LDAP within its products for authentication of users in the network, accessing information about users, managing product configurations, and network hardware / software inventories.

LDAP directories are now provided by IBM on OS/390, i5/OS, AIX and NT. All of these directories are compatible with each other and utilize DB2 for storing directory information.

LDAP clients, providing APIs to access LDAP servers using TCP/IP, are available for most major platforms. APIs are available in C and Java and are based on industry standards.

Since V4R3, LDAP has been included free in i5/OS as part of i5/OS Directory Services (option 32). Directory Services includes an LDAP server and complete set of LDAP clients and utilities.

The LDAP server uses DB2/400 for storing the directory information and is configured using System i Operations Navigator.

The i5/OS LDAP client supports accessing any LDAP server from all i5/OS ILE programming languages; C, COBOL and RPG. An LDAP client for Windows is included with i5/OS Client Access and a Java client is included in i5/OS's support of Java Naming and Directory (JNDI).

Command line utilities are provided for accessing an LDAP server from Windows and i5/OS. These utilities are compatible with LDAP utilities provided for other operating systems and allow you to search, add, modify and delete directory information.

After configuring i5/OS to use LDAP, you'll want to start taking advantage of the LDAP directory. Included with Directory Services are utilities for publishing information about System i users into an LDAP server. This includes their names, e-mail addresses, telephone numbers and user ids. You can access this information in the directory using any LDAP client application, such as a mail client (Lotus Notes, Netscape Communicator, Microsoft Exchange, etc.). When sending mail to System i users, these clients can be configured to extend their address books to search your System i LDAP directory. Next month we'll take a closer look at publishing System i user information into the directory.

i5/OS also supports storing network hardware and software inventory an LDAP directory. NetFinity for System i publishes workstation and server inventory in an LDAP directory. You to search an LDAP directory for network configuration information such as a workstation's motherboard information or an System i's software configuration. Also, i5/OS V4R4 supports publishing System i software and hardware configuration information in the directory.

You can extend the use of the directory in may ways through LDAP enabled applications that you purchase or develop yourself. The following are some examples:

Earlier we mentioned that you can publish System i user information in the directory. Information about System i users is published to the directory when you manage your System i user information using i5/OS System Distribution Directory commands or System i Operations Navigator. This is an easy way to get started, but you may want additional user information stored in the directory. You can add information to the directory for one user or a group of users using command line utilities provided with Directory Services. To extend your management of user information, you can develop your own utilities or purchase products such as System i Directory Assistant from Boldon James which integrates with System i Operations Navigator.

LDAP directory servers use a data definition called a schema to identify the type and format of information stored in the directory. IBM has developed a schema based on Internet standards and extensions required by IBM servers and products. LDAP servers use the schema definition to define the objects and their properties that are stored in the directory. A directory object is defined by one or more object classes, such as ePerson. These object classes define a set of object properties called attributes to be used when accessing the directory object. For example, Directory Services uses serveral object classes (person, organizationalPerson, inetOrgPerson and ePerson) to define System i users in the directory. Collectively, these object classes define personal information such as a person's name, phone number and e-mail address.

The IBM schema used by the Directory Services LDAP server consists of several hundred object classes and over six hundred attributes. The schema is stored in text files that you can extend and change with a text editor as required by your applications. For example, you can extend the ePerson object classes with additional attributes to store information specific to your organization. Once the schema is extended, you can develop LDAP enabled applications to store additional information in the directory, thus allowing you to manage all information about a user in one directory object. Once in the directory, you can develop applications to access the information from any platform in your enterprise.

Suppose you have two System i's in your network that manage databases of Human Resource (HR) information for your employees. To start, you can configure an LDAP server on one of your System i's to support an LDAP directory for your network. Utilities provided with Directory Services enable you to easily publish user information from both System i's to the directory. However, you can also extend the System i LDAP server's schema to include your HR information by editing the schema files on the System i. For example, you can extend the IBM ePerson object classes with additional attributes to allow your to store employee's date of initial service and their salary. After extending the LDAP server's schema, you will probably want to develop an System i utility to publish your HR's database into the directory. Directory Services provides an extension to the standard LDAP API's for publishing information to the LDAP directory. These special i5/OS publishing APIs can be used by your utility to efficiently publish your HR information without detailed knowledge of LDAP specifics, such as how to locate and connect to the LDAP server.

LDAP is the standard for Internet directories in a heterogeneous network. Regardless of the directory's implementation, LDAP provides applications with a consistent view and access method for information in the network. Initially LDAP directories focused on personal information such as names and addresses, but LDAP directories are becoming the foundation for network operating systems and systems management. As shown here, you can use i5/OS support of LDAP in your network to simplify access to information.