Solaris 8 with OpenLDAP: Introduction to LDAP

What is LDAP?

LDAP is merely a protocol used for accessing a directory service. LDAP is not a database. LDAP is not a directory server. LDAP is a protocol. OpenLDAP is directory server software which listens for LDAP requests, and performs lookups in a "backend" database. Typically, the backend database is a BerkeleyDB style database. DB/DBM database lend themselves to LDAP very well, since the LDAP protocol represents data as key/value pairs.

The most important feature that an LDAP server software can possess is speed. By the nature of its use, LDAP servers must be optimized for reads. By that, I mean they must be able to handle lookups (reads) extremely efficiently. The data in a directory server is -- for the most part -- static. Changes are fairly infrequent. As such, it is acceptable for database writes (inserts) to suffer at the cost of quick reads.

The structure of an LDAP database is somewhat similar to a NIS+ database. The structure of the LDAP database is comparable to that of a filesystem hierarchy. For example, each file has an exact path in the filesystem. For example, the path to 'ls' is /usr/bin/ls. The path to perl may be /usr/local/bin/perl. These paths can be broken up into parts. For example, the path to perl (in this example) is:

/usr/local/bin/perl


/ (root)
|
+---- usr
       |
       +----- local
                |
                +------ bin
                         |
                         +------- perl
The path is read from left to right when dealing with filesystems. With LDAP, the path is read from right to left. For example:

uid=ekilfoil,ou=People,dc=ViaWest,dc=Net

is a full path to an LDAP entry. Graphically, it is represented as:

dc=net (root)
|
+---- dc=ViaWest
       |
       +----- ou=People
                |
                +------ uid=edk
The actual ldap tree may look something like this:

dc=net (root)
|
+---- dc=ViaWest
       |
       +----- ou=Employees
       |        |
       |        +------ uid=abradford
       |        |
       |        +------ uid=edk
       |        |
       |        +------ uid=ibrezac
       |        |
       |        +------ uid=mselders
       |
       +----- ou=People
                |
                +------ uid=bsmith
                |
                +------ uid=bbonenberger
                |
                +------ uid=sraab
Here are some terms that will be used throughout this documentation that you should feel comfortable with:
  • DN: Distinguished Name
      The direct path to an entry in the directory server. A DN is represented by a comma separated list of key/value pairs. For example:
        cn=ekilfoil,ou=People,dc=ViaWest,dc=Net
      A DN points to a specific entry in the directory.
  • BaseDN: Base Distinguished Name
      In terms of searches, this is the directory within the directory server at which a search starts. For example, searching with a BaseDN of ou=People,dc=ViaWest,dc=Net will never return an entry from outside of the ou=People directory.
  • BindDN: Bind Distinguished Name
      The BindDN can be thought of as a username. This is the username that you are supplying to the directory server for authentication and authorization purposes.
  • RootDN: Root Distinguished Name
      The RootDN is a special BindDN. The RootDN is not susceptible to any access restrictions for making modifications to the directory.
  • Entry:
      An entry is an object in the directory which contains data. If you think of a filesystem as a group of leaves and branches you can imagine that a directory contains very specific information, while files can contain any type of information. This is not the case with LDAP. There is not real distinction between a leaf and a branch.
      A DN points to a specific entry in the directory.
  • Object:
      Object is merely another term for an entry. You may find that they are used almost interchangably in this document. An Object is NOT the same as an ObjectClass.
  • Key/Value:
      Key/Value is a term which means that data can be accessed by an identifier called a key. An common example of a key/value pair would be:

      Key: uid
      Value: edk

      Key: homeDirectory
      Value: /export/home/edk

      This is merely a simple method of representing the type and the value of the data.

  • Schema:
      Schema is defined as "A diagrammatic representation; an outline or a model." An LDAP schema actually has two very different meanings.
      1. The structure or hierarchy of the LDAP tree.
        The graphical representation of the LDAP database (as seen above) can be referred to as the schema.
      2. The type of data that can be contained within an entry.
        The schema defines what key/value pairs a specific entry is allowed to contain. This definition is done with ObjectClasses (we'll get to that later).
  • slapd:
      slapd is the name of OpenLDAP's server binary. This program is the process which actually serves incoming LDAP requests.
  • Master LDAP server:
      The master LDAP server contains the authoritative data for the directory. All updates must be performed on the master LDAP server.
  • Replica LDAP server:
      Replica LDAP servers are exact replicas of the master LDAP server and are used for load balancing and redundancy.
  • slurpd:
      slurpd is the name of OpenLDAP's replication binary. This program watches for modifications to the LDAP directory, and then performs updates to any replica servers.
  • posixAccount:
      Simply put, a POSIX Account is a standard UNIX user account.
  • LDIF: LDAP Data Interchange Format
      LDIF is a method for representing data in an LDAP directory in a human readable format. The LDIF format is used for adding, deleting, and modifying data within the LDAP directory.
Next: Security