The LDAP model is based on entries, which are collections of attributes that describe the directory structure. Attributes each have names, types, and corresponding values (“Understanding LDAP,” 2004).
Entries are arranged in an upside-down tree-like pattern, starting with a root and branching out into the individual entries. The further towards the root the tree is traversed, the larger the organization, and the further away from the root the smaller the organizational units become, which may terminate in units as small as individual users (“Understanding LDAP,” 2004).Every entry in the tree is uniquely identified by what is called a distinguished name. It consists of a name that identifies that entry within its level of the tree, and a path of names that reveal the path back to the root of the tree (“Understanding LDAP,” 2004). Thus a DN is always read left to right, with the smallest unit beginning on the left and the top level on the right.
The top level of the tree is known as the “base DN.” Most LDAP implementations have begun using DNS as the basis for the base DN, so the root of the directory is usually the domain name of the organization (Donnelly, 2000). From there the entry is broken down into smaller organizational units, such as the class of the entity (“employees,” “workstations,” etc.), business divisions, or any other sensible class. An example of a full DN might be:
- cn=John Smith,ou=contractors,dc=blackbox,dc=com
In the above example, the CN preceding John Smith stands for Common Name, and in the case of LDAP records this is usually a person’s full name. The OU stands for organizational unit, which is just an arbitrary logical division. The DC in the last two attributes stands for Domain Component.
LDAP stores all of this directory information through the use of the standard text files adhering to the LDAP Interchange Format (LDIF). LDIF allows LDAP to read and store configuration information and directory contents. It is nothing more than a text file consisting of a collection of entries separated by blank lines, attribute names mapped to values, and a collection of instructions to direct the parser on how to process the information (Carter, 2003). Since entries are stored as a series of attribute pairs (attribute type-attribute value), this makes LDAP’s method of storage entirely different from the way a relational database would do the same (Donnelly, 2000).
Like most other services, LDAP follows the client-server model. An LDAP server listens for incoming connections on port 389 and makes information about organizations and their units within accessible to LDAP clients. Clients can initiate certain operations within the LDAP server, such as:
- Searching for entries in the directory
- Adding new entries
- Updating entries
- Deleting entries
- Renaming entries (“Understanding LDAP,” 2004)
If a client wishes to update an entry in the directory, the client submits the distinguished name of the entry with the updated information to the server. The server uses the distinguished name to find the corresponding entry and make the changes to it (“Understanding LDAP,” 2004).