Understanding LDAP (part 1) - Looking For Answers
(Page 3 of 5 )
Put very simply, LDAP is a protocol designed to allow quick, efficient searches of directory services. Built around Internet technologies, LDAP makes it possible to easily update and query directory services over standard TCP/IP connections, and includes a host of powerful features, including security, access control, data replication and support for Unicode.
LDAP is based largely on DAP, the Directory Access Protocol, which was designed for communication between directory servers and clients compliant to the X.500 standard. DAP is, however, fairly complex to implement and use, and is not suitable for the Web; LDAP is a simpler, faster alternative offering much of the same basic functionality without the performance overhead and deployment difficulties of DAP.
Since LDAP is built for a networked world, it is based on a client-server model. The system consists of one (or more) LDAP servers, which host the public directory service, and multiple clients, which connect to the server to perform queries and retrieve results. LDAP clients are today built into most common address book applications, including email clients like Microsoft Outlook and Qualcomm Eudora; however, since LDAP-compliant directories can store a diverse range of data (not just names and phone numbers), LDAP clients are also increasingly making an appearance in other applications.
Here's a simplified diagram of how LDAP clients and servers work.
As you can see, the system above comprises three LDAP servers, each one handling a different section of the global directory. Client queries are either resolved immediately by the server to which they are directed (if that server has the requested information) or referred to another server for resolution. This redundancy between servers is what makes LDAP so suitable for the distributed nature of the Web - a single directory may be split across multiple servers in different locations and merged together at leveraged connection points to work as a single, unified database.
If you're familiar with how the Internet Domain Name System (DNS) works, you'll see numerous similarities between that model and the one described above - both are global directories split across multiple hosts, both contain built-in redundancy and replication features, and both include referral capabilities that make it possible to retrieve data that is not available locally from other hosts in the system.{mospagebreak title=Up A Tree} An LDAP directory is usually structured hierarchically, as a tree of nodes (the LDAP directory tree is sometimes referred to as the Directory Information Tree, or DIT). Each node represents a record, or "entry", in the LDAP database.
An LDAP entry consists of numerous attribute-value pairs, and is uniquely identified by what is known as a "distinguished name" or "DN". Consider the following diagram, which illustrates:
If you're familiar with RDBMS, it's pretty easy to draw an analogy here: an LDAP entry is analogous to a record, its attributes are the fields of that record, and a DN is a primary key that uniquely identifies each record.
Consider the following example of an LDAP entry, which might help make things clearer:
dn: mail=joe@melonfire.com, dc=melonfire, dc=com
objectclass: inetOrgPerson
cn: Joe
sn: Somebody
mail: joe@melonfire.com
telephoneNumber: 1 234 567 8912
This is an entry for a single person, Joe Somebody, who works
at Melonfire. As you can see, the different components of the entry - name, email address, telephone number - are split into attribute-value pairs, with the entire record identified by a unique DN (the first line of the entry). Some of these attributes are required and some are optional, depending on the object class being used for the entry (more on this later); however, the entire set of data constitutes a single entry, or node, on the LDAP directory tree.
Wondering how a DN is created? Well, every entry in the directory tree has what is known as a "relative distinguished name" or "RDN", which consists of one or more attribute-value pairs and must be unique at that level in the directory hierarchy. In the example above, for instance, the following are all valid RDNs for the entry:
cn=Joe
or
cn=Joe+sn=Somebody
or
cn=Joe+sn=Somebody+telephoneNumber=12345678912
or
mail=joe@melonfire.com
In other words, there are no hard and fast rules as to which
attributes of a particular entry should be used for the RDN; the LDAP model leaves this decision to the directory designer, simply specifying that the RDN of an entry must be such that it can uniquely identify that entry at that level in the DIT.
Now, since RDNs exist for each and every entry in the tree, the DN for any entry is formed by appending the RDNs of all the nodes between that entry and the root entry to each other. The DN thus makes it possible to easily locate any node in the directory tree, regardless of its location or depth in the hierarchy.
In order to better understand this, let's take a simple example. Consider the following LDAP directory:
rdn: c=IN [dn:c=IN]
|
|
| --- rdn: o=Melonfire [dn:o=Melonfire,c=IN]
|
|
| --- rdn: ou=Executives [dn:ou=Executives,o=Melonfire,c=IN]
| |
| |
| | --- rdn: uid=sarah
[dn:uid=sarah,ou=Executives,o=Melonfire,c=IN]
|
| --- rdn: ou=Worker Bees [dn:ou=Worker Bees,o=Melonfire,c=IN]
|
|
| --- rdn: uid=joe [dn:uid=joe,ou=Worker
Bees,o=Melonfire,c=IN]
|
|
| --- rdn: uid=john [dn:uid=john,uid=joe,ou=Worker
Bees,o=Melonfire,c=IN]
Now, in order to identify the node belonging to Joe Somebody
- in other words, to obtain the DN for Joe Somebody's entry - all you need to do is add up all the RDNs between that entry and the root of the tree. Doing this, you get
uid=joe,ou=Worker Bees,o=Melonfire,c=IN
In a similar manner, the DN for the node belonging to Sarah
would be
uid=sarah,ou=Executives,o=Melonfire,c=IN
while the DN for the Melonfire node would be
o=Melonfire,c=IN
Since LDAP entries are arranged in a hierarchical tree, and
since each node on the tree can be uniquely identified by a DN, the LDAP model lends itself well to sophisticated queries and powerful search filters. For example, I could restrict my search to a particular subset of the tree simply by specifying a different base for the query to begin from, or query only against specific attributes in the directory tree. Heck, I could even do both, and feel like a Real Programmer!
Next: Treating Entries As Objects >>
More Administration Articles
More By Vikram Vaswani, (c) Melonfire
