A directory is a specialized database optimized for reading, browsing and searching. Directories tend to contain descriptive, attribute-based information and support sophisticated filtering capabilities. Directories generally do not support complicated transaction or roll-back schemes found in database management systems designed for handling high-volume complex updates.
Directory updates are typically simple all-or-nothing changes, if they are allowed at all. Directories are tuned to give quick response to high-volume lookup or search operations. They may have the ability to replicate information widely in order to increase availability and reliability, while reducing response time. When directory information is replicated, temporary inconsistencies between the replicas may be okay, as long as they get in sync eventually.
Because of this, directory services generally have the following five characteristics (page 3):
A directory service is highly optimized for reads
A directory service impliments a distributed model for storing information
A directory service can extend the types of information it stores
A directory service has advanced search capabilities
A directory service has loosely consistent replication among directory servers
There are many different ways to provide a directory service. Different methods allow different kinds of information to be stored in the directory, place different requirements on how that information can be referenced, queried and updated, how it is protected from unauthorized access, etc. Some directory services are local, providing service to a restricted context (e.g., the finger service on a single machine). Other services are global, providing service to a much broader context (e.g., the entire Internet). Global services are usually distributed, meaning that the data they contain is spread across many machines, all of which cooperate to provide the directory service. Typically a global service defines a uniform namespace which gives the same view of the data no matter where you are in relation to the data itself. The Internet Domain Name System (DNS) is an example of a globally distributed directory service.
What is LDAP?
LDAP stands for Lightweight Directory Access Protocol. As the name suggests, it is a lightweight protocol for accessing directory services, specifically X.500-based directory services. LDAP runs over TCP/IP or other connection oriented transfer services. The nitty-gritty details of LDAP are defined in RFC 2251 "The Lightweight Directory Access Protocol (v3)" and other documents comprising the technical specification RFC 3377.
What kind of information can be stored in the directory?
The LDAP information model is based on entries. An entry is a collection of attributes that has a globally-unique Distinguished Name (DN). The DN is used to refer to the entry unambiguously. Each of the entry's attributes has a type and one or more values. The types are typically mnemonic strings, like "cn" for common name, or "mail" for email address. The syntax of values depend on the attribute type. For example, a cn attribute might contain the value Frank Poole. A mail attribute might contain the value "frank@example.com". A jpegPhoto attribute would contain a photograph in the JPEG (binary) format.
So what's all the fuss about?
So this is a directory server, big deal! What can LDAP offer the system administrator above and beyond Just Another Phonebook? The answer to this question is, "a lot".
Firstly, LDAP's abstraction allows it to store a wide variety of information. Everything from simple phonebooks to more complicated authentication schemes can be accessed with it. Second, servers such as OpenLDAP (which we will be looking at in this class) can be integrated with other servers such as SAMBA and NIS offering seamless integration of data across platforms. Third, such integration can greatly reduce the amount of data redundancy across servers and platforms.
Taking a look at the advantages for SAMBA and UNIX authentication the strengths become immediately evident. On a UNIX or Linux system, there is an underlying UNIX authentication that goes on with every transaction. There are users accessing the UNIX system with specific access rights and priviledges.
SAMBA is built on top of this underlying UNIX system and allows communication and file or printer sharing across Windows and UNIX platforms. While SAMBA does use the underlying UNIX authentication when dealing with the file system, it adds its own layer of authentication built on top of this which it uses to interface with the Windows clients or servers. If the underlying UNIX layer and the SAMBA layer both contain common items, then there will undoubtedly be a lot of data redundancy (a user "poole" under UNIX may be linked to the user "frank" in SAMBA). This data redundancy means more work for the system administrator when components, users, or rights get changed, and create a situation where administrator error can easily creep in.
By integrating the two into an LDAP server, you have a one stop shop for user account modification. You also have a single location which authenticates a number of diverse components.
Of course, you also have a single location which can be compromised, so there are precautions that should be taken. We will examine these precautions as we go.
How is the LDAP information arranged?
In LDAP, directory entries are arranged in a hierarchical tree-like structure. Traditionally, this structure reflected the geographic and/or organizational boundaries. Entries representing countries appear at the top of the tree. Below them are entries representing states and national organizations.
The tree may also be arranged based upon Internet domain names. This naming approach is becoming increasing popular as it allows for directory services to be located using the DNS.
