LDAP is the Lightweight Directory Access Protocol. It is a "meta-database" - a way of accessing a databse backend. Its primary features are human readability, ease of use, security, and interoperability. Just about any type of data may be stored in LDAP; some examples of current applications are:
- Mail aliases and quotas
- Public/Private keys, SSL certificates, etc.
- NIS information/authentication
- Kerberos Principals (!)
- Address books
- Virtual host configurations
The list goes on.
The basic idea of LDAP is that all information is stored in a tree. Rather than trying to explain in detail, here is a set of facts:
- Every node in the tree may both store information of its own and contain any number of "children".
- All data is stored in name:value pairs.
- Every node has one or more "objectClass" attributes, which determine the "syntax" - which attributes the object may hold. This syntax is defined in the "schema file".
- Attributes have a syntax as well, which determines what values they may hold and whether there may be multiple values of the attribute on a single node. All attributes are allowed to hold an infinite number of values unless SINGLE-VALUE is specified in the schema file.
- Searching and reading is much faster than writing. Searching for value matches, especially, is very fast in LDAP.
- All nodes have a "distinguished name" (dn) which identifies in a globally-unique fashion. The "dn" comprises the "naming attribute" of the node (which may be any attribute it has a value for), plus the dn of the node's parents.
- The standard dump of an LDAP database is called an LDIF (Lightweight Data Interchange Format). The LDIF of a user might look like this:
dn: uid=root,ou=people,dc=tjhsst,dc=edu objectClass: posixAccount uid: root cn: Richard Oot givenName: Richard sn: Oot uidNumber: 0
LDAP provides for two types of authentication: simple, and SASL. When a user authenticates to the server, they perform a process called "binding" - they BECOME a node in the LDAP tree. From that point on, access control is performed based on the values of attributes in the "bind DN" - the user's authorization identity. SASL binding is most interesting when it uses Kerberos authentication - no passwords are required, the LDAP server simply maps the Kerberos principal name into an LDAP DN (or performs a search of the LDAP tree to locate a suitable entry).