Introduction to LDAP

The following is a brief introduction to the LDAP structure and function. For more information refer to z/OS IBM Tivoli Directory Server Administration and Use for z/OSz/OS IBM Tivoli Directory Server Administration and Use for z/OS.

LDAP is an Internet Protocol Standard based on the TCP/IP protocol. LDAP stands for Lightweight Directory Access Protocol.

LDAP is a protocol which makes directory information accessible. A directory can be considered to be a type of yellow pages. New entries can be added, existing entries can be altered or deleted, and it is possible to search for all matching entries using wildcards.

The LDAP directory is represented hierarchically in a so-called Directory Information Tree (DIT). The nodes of this tree are called entries. Every entry is an instance of an object class. An object class is a name which is associated with a collection of attributes.

Every attribute is either mandatory (required) or optional and either single valued or multi valued. Required attributes must have one or more values, optional attributes can have zero or more values. One required single valued attribute of every object class is objectclass: This attribute specifies the object class of which the entry is an instance.

Each entry has a relative distinguished name (RDN) which is specified when the entry is created. The RDN must identify the entry uniquely among its siblings (not necessarily in the whole tree); it consists of one or more attribute-value pairs. The distinguished name (DN) of an entry is the sequence of the RDNs starting from the entry itself and ending with the RDN of the root entry. The DN identifies a node uniquely within the whole DIT.

An example for a DN of a partition within a DIT for HCD IODFs would be the following:

hcdPartitionId=PART00,hcdProcessorConfigId=PROC00,
hcdIodfId=SYS1.IODF00,cn=HCD

This is illustrated in the following figure.

Figure 148. Sample DIT portion of the HCD LDAP backend

IBM Tivoli Directory Server for z/OS owns a DIT which can be accessed by a client via the LDAP protocol. In the case of the IBM Tivoli Directory Server for z/OS, the task of storing the DIT is delegated to several so-called backends or plug-ins. Each plug-in holds a certain subtree portion and is responsible for carrying out the client's requests on this portion. The DN of the root entry of a plug-in is called a suffix. When the IBM Tivoli Directory Server for z/OS receives a request concerning an entry it extracts the suffix from the DN of that entry in order to determine which plug-in is responsible for the request.

HCD supports the IBM Tivoli Directory Server for z/OS by providing the HCD LDAP backend plug-in which makes IODFs accessible via the LDAP protocol.