Directories are one of the most common database structures. They are lists of things with their various attributes. The things are objects, real or imaginary. Either way, they are treated the same.

Examples of real world directories are old-school telephone directories (name, address, phone number), customer lists, library catalogs, password files, student rosters, etc. These are among the earliest databases implemented on punched cards and then converted to tape, disk, and SSD.

Generally, the purpose of a directory is to make it easy for people or computers to “look up” the information about something. In paper telephone directories, the listings (entries) were sorted by last name (surname), then first name (given name). You found someone’s entry by alphabetic search. In punched cards, you could sort the cards into the same order then create a list. Early computers let you run simple programs to find the entry very quickly. As computer programs got more complex, finding entries quicker meant databases stored on faster devices, finally on disk and SSD.

These directory databases were implemented with many different database technologies: flat (sequential) files, simple indexed direct (random) access files, older database technologies, and relational database management systems (RDBMSs, SQL). That meant that different directories in the same firm often needed very different programming. It also meant that when a package bought from a vendor was installed, it brought very different directory technology with it.

Companies recognized that all directories are really quite similar. They store similar kinds of data. They are used in much the same way. So, with some thought, a “Directory Services Standard” could be developed. The first standard, named X.500 Directory Access Protocol(?) (DAP), was an International Standards Organization (ISO) and International Electrotechnical Commission (IEC) combined effort. It was an outgrowth of a networking standard (X.400).

The standard was released in 1989, and many technologists were following its development. Several implementations were developed by those working with X.400 networks. But the Internet was rapidly overtaking X.400. A simplified version of the standard was developed within the Internet Engineering Task Force (IETF) and called the Light-Weight Directory Access Protocol (LDAP). It was implemented at the University of Michigan as a verification tool and reference for others.

Both X.500 DAP and LDAP have two core capabilities. First, they define a data model from which actual supporting databases can be designed and built. Second, they define a network access protocol for using the database. Both of these capabilities are similar in X.500 and LDAP. The LDAP committee worked hard to define a proper subset of X.500 so make programming for them as similar as possible.

These directory services standards are now widely adopted. The industry has thirty years or so of experience with them. The original designers had a “grand vision” of a global directory made up of many interconnected directories so that, with appropriate access control (permissions), a search could be sent to a central (global, national, industrial, etc.) directory and the data be sent from some more specialized directory. This was done through “referrals”. When a request was made that couldn’t be answered locally, that directory could contain information on where to refer the client application to find the data. The application would then forward the referral(s) and get the information.

There were several such global directories set up. The X.500 and LDAP communities were quite committed to those capabilities. However, most firms, agencies, and institutions were/are more interested in their own internal directories. The “referral” system is still supported but most LDAP client applications don’t support referrals in favor simplicity.

Many, many applications now support authentication (login approval) and authorization (getting permission data) from an enterprise’s private authoritative directory. LDAP is becoming pervasive in the Internet user community.

The directory service supports various kinds of requests. By far, the most common two are BIND (log in to the directory and establish permissions) and SRCH (search or query). The database is maintained via the network using the ADD, MOD (modify), and DEL (delete) requests. There are also CMP (compare), MODRDN (a simplified modify for a specific kind of attribute), UNBIND, and EXTERNAL (rare).

It is entirely possible to start the LDAP server with all the data definitions and other configuration information but with an empty database. Then you load the data “over the network” (really or simulating it with local utility programs) using the LDAP Data Interchange Format (LDIF), a text representation of directory data. LDIF is easily created and edited with a text editor. LDIF can also be used to modify and delete entries. There are utilities to query the database locally as well.

© 2020-23 Symas Corporation. All rights reserved.