An LDAP directory is a listing of information about objects arranged in a particular order that gives details about each object. LDAP is a specialized database that has characteristics that set it apart from general purpose relational databases.
One special characteristic of directories is that they are accessed (read or searched) much more often than they are updated (written). Hundreds of people might look up an individual's phone number, but the phone number rarely changes.
IBM® Telephone
Directory V5.2 is used to search, view, and manage entries in an existing
directory, or it is used to set up a new directory. The application uses an
LDAP directory server to store and retrieve data. By default, the LDAP server
is automatically configured on your iSeries™ server unless
another LDAP server already exists in your network. The LDAP server is not
required to reside on the same iSeries server as
the application server. In addition, you can also use a Domino® LDAP server
with IBM Telephone
Directory. For more information, see the Redpaper WebSphere® Application Server Express on iSeries. 
The LDAP server is accessible through TCP/IP. You perform most LDAP server setup and administration tasks using iSeries Navigator. You must have iSeries Navigator installed on a workstation that is connected to your server.
LDAP entries
The only default setting of IBM Telephone Directory V5.2 installation is to allow users to anonymously search the directory.
When you use IBM Telephone Directory V5.2 application to add an entry to the directory, an entry is created in the user's parent DN and uses the user ID value. For example, if you register John Jones in the cn=users,dc=myhost,dc=mycompany,dc=com parent DN, his LDAP entry is cn=John Jones,cn=users,dc=myhost,dc=mycompany,dc=com. The parent DN update is hidden from the user and from the IBM Telephone Directory V5.2 administrator. Objects in a directory are referenced by a distinguished name (DN) attribute. During authentication, John is prompted for his user ID. He must enter the user ID that was specified during registration. In this example, his user name is John Jones.
Existing directory entries can be searched, viewed, and managed if they are based on the standard inetOrgPerson object class.This object class is an industry standard class that is commonly used to represent and store information about people, such as first and last name, telephone numbers, and email addresses. The directory can contain entries for other object classes, such as those object classes used by the application to search the directory; however, the default object class is inetOrgPerson.
Directory entries modified by the application have an auxiliary object class added to them called ibm-itdPerson. The ibm-itdPerson object class allows the IBM Telephone Directory V5.2 application to use additional attributes not available with standard object classes. Additional attributes include alternate phone numbers, alternate addresses, DN values for assistants and backups, as well as work location information including job responsibility, marketing territory, and trade area. All attributes in the auxiliary ibm-itdPerson object class are optional. The class is added to provide a way to store additional information about a person that is not included in the inetOrgPerson object class.
Once the application receives a request, it must connect to the LDAP server to act on it. Requests are carried out under the authority of the user that is specified. The application uses credentials passed on HTTP requests to connect to the LDAP server, if necessary. The application requires credentials for some requests, such as a request to create, update, or delete directory entries. Credentials required to add new entries are provided by the administrator when open enrollment is enabled.
If credentials are not required to do search requests, the application connects to the LDAP server using anonymous bind to search the directory. For anonymous search access, the Directory access configuration property must be set to Anonymous (no login). If credentials are required to do search requests, the application connects to the LDAP server using the user credentials that are passed on the HTTP requests. The request fails if credentials are not provided. For authenticated search access, the Directory access configuration property must be set to Login Required. See Modify directory access for more information.
The LDAP server controls what users are authorized to do and whether their requests succeed or fail. This includes anonymous user requests. All authorization settings for the directory are specified and controlled by the LDAP server. The application transforms HTTP requests into LDAP requests, ensures credentials are securely handled and supplied to the LDAP sever, and formats the LDAP results (success or failure) into HTML pages that resemble a simple address book.
Users provide the credentials that the application uses to connect to the LDAP server. User credentials are not used to connect to the LDAP server when open enrollment is specified. For open enrollment, credentials are read from the application's configuration file. The HTTP server is required to authenticate the user when necessary. The application uses the credentials supplied on each request (when necessary) to connect to the LDAP server. The application does not cache credentials or reuse LDAP connections to handle multiple HTTP requests. LDAP connections are disconnected after each request, which prevents the application from connecting using a user's credentials to fulfill the request of another user. If the HTTP server does not provide the credentials needed to connect to the LDAP server, the application fails.
For more information about iSeries Directory Server (LDAP), see the following topics:
- Directory Server (LDAP)
- iSeries Directory
Server (LDAP) (http://www.ibm.com/servers/eserver/iseries/ldap)
The Articles and Publications section has links to articles, redbooks and other related LDAP books.