LDAP, created in the early 1990s by the University of Michigan, went through some serious changes even before coming into wide use. LDAP version 3 is the result of a late 1998 upgrade;
it just recently went through the standardization
phase at the Internet Engineering Task Force. It is now presented in a group of proposed standards, RFCs 2251 through 2256. In
the years since its original development, LDAP has gone from a
lightweight replacement for the OSI X.500 Directory Access Protocol to a general-purpose directory service for IP networks.
LDAP version 3 extends the protocol with security features, multilingual support, new extensible LDAP commands, methods to discover the features and the schema of an LDAP server, and the ability to send referrals to other servers.
Bind operations between an LDAP client and a server are now
authenticated using the Simple Authentication and Security Layer (SASL) standard or the Transport Layer Security (TLS) standard. These use certificate-based authentication to make sure the two parties
are who they say they are.
With Unicode and the UTF-8 encoding system, LDAP is no longer confined to the standard ASCII alphabet. Any language supported in Unicode can now be represented in LDAP data. However, this doesn't mean LDAP servers will naturally perform searches in any language.
Language-based searches still have to be built into the server before this happens. However, the server will be able to match exact strings to one another simply by matching characters in the character set.
Previous to the release of LDAP version 3, the client had to have a
concept of how the DIT and schema were stored ahead of time. This meant that only precoded LDAP requests that were aware of the DIT would work successfully. Any change to the server DIT meant clients sometimes had to be modified appropriately. The new version allows an LDAP client to discover the schema and DIT of any server by querying a special node known as the root directory specific entry (rootDSE). Typically, the client isn't able to change the properties of the rootDSE, but it is able to read what the directory schema contains and how it is structured. Any change to the rootDSE may affect how the client interacts with the LDAP server.
LDAP version 3 servers can now redirect client queries to other servers. This allows load-balancing amongst servers as well as the partitioning of the information across multiple servers. A particular DIT can be split into separate domains, each containing a subtree of the whole DIT. LDAP servers can thus redirect a query to the DIT that is contained in a separate domain.
LDAP version 3 changes the way in which command operations are described, so that new commands can be created in the future to enhance the function of the directory service. The previous set of commands to read, write, delete, compare, and search attributes of a DN, or the DNs themselves, still exist. New commands, such as referrals modifying a DN and all its subnodes, are now
also possible. The bind command has also been altered to work with the new SASL security mechanism to perform authentication when the session is being set up.
The structure of this latest version of LDAP makes it extensible, and
the work of related protocols, such as LDUP, make it scalable. Although it is quite possible that new versions will still come out, for now and for the next few years LDAP version 3 should suit most users just fine.
Currently, the client-to-server communications side is well defined. The basic command set of LDAP is enough to provide all that client
applications should need. With the addition of the extended command
operation in LDAP version 3, there is even room to add more operations, should the need arise. You can also expect that some vendors will create proprietary extended operations to fit the needs of their environments.
Unfortunately, the server-to-server communications side is still in the Internet draft process. Some vendors, such as Microsoft, have already implemented some of these drafts, along with their own extensions. The drafts should be formalized into full standards between August and December of 1999. A separate protocol, known as the LDAP Duplication Protocol (LDUP), will serve this purpose.
LDAP architecture
The basic structure of LDAP is a simple tree of information. Starting at a root node, it contains a hierarchical view of all its data and
provides a tree-based search system for them (this is one of the most common ways to search data). The actual data contents can vary, depending on how you use the LDAP server. For example, you could have a set of LDAP servers focused solely on servicing login information requests for the thousands of users you support. Another server could contain host address information used by your DNS and DHCP servers. On the other hand, if you don't have that large of a network, you could even combine the information into a single tree.
The tree itself is called the directory information tree (DIT). Subtrees of the DIT contain all the information on that LDAP server. Every node in the tree is known as an entry, or directory service entry (DSE). These entries contain the actual records that describe different real and abstract objects in the computing environment, such as users, computers, preferences, etc. Some entries can be aliases leading to other parts of the directory, if the real contents already exist somewhere else. The root node of the tree doesn't really exist and can't be accessed directly. There is a special entry called the root directory specific entry, or rootDSE, that contains a description of the whole tree, its layout, and its contents, but this really isn't the root of the tree itself.
Each entry contains a set of properties, or attributes, in
which data values are stored. Simply said, each entry is a datastructure of variables. For example, a tree defining the crew of the starship Red Dwarf could start with a hierarchical description of the ranks of the crew, starting from Captain at the top, and going down to Assistant Technician's Mate at the bottom. At each rank, there would be a single person as well as links to those subordinate to that rank. Each person (entry) would have attributes such as his or her name, serial number, office location, e-mail address, etc. Each attribute would in turn have a specific value; e.g., the name attribute could have the value of Arnold
Rimmer, while the e-mail address attribute would have the value of
rimmer@reddwarf.example. As you can see, the actual
data contained can be fairly small. Of course, you could have other
attributes, like a 3D representation of the person, which could be a very large piece of data; typically, however, the LDAP node would simply contain a pointer to the place where the actual contents of such a large value would be located.
To refer to each entry in the DIT uniquely, you must use a
distinguished name (DN). Normally, this is the very first attribute of the entry. The DN presents the full name of the entry within the entire tree. For example, the DN for our Mr. Rimmer could be:
uid=rimmer, ou=technicians, dc=reddwarf, dc=example
Having to specify the DN every single time to access an entry could
become cumbersome, especially when you're just looking at a small subset of the tree. If you already know which subset you're examining, you need only specify the name relative to this position. Each of these are thus relative distinguished names (RDNs). For example, relative to reddwarf.example there can be several names:
uid=rimmer, ou=technicians
uid=lister, ou=technicians
uid=scutter1, ou=robots
uid=scutter2, ou=robots
uid=kryten, ou=androids
uid=cat, ou=resultsof3millionyearsofcatinbreedingandevolution
The LDIF record
The LDAP Data Interchange Format (LDIF) is commonly used to
define records within the DIT. This is typically a text file describing the various elements within a record and how it is organized. Starting with the DN, the example below shows the user rimmer at the domain reddwarf.example ("example" is a new top-level domain, just like com, net, org, and edu).
dn: uid=rimmer, ou=technicians, dc=reddwarf, dc=example
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
cn: Arnold J. Rimmer
cn: The Git
sn: Rimmer
mail: rimmer@reddwarf.example
description: He's just a git
homeLocation: bottom bunk
dislikes: gazpacho soup
objectClass: organization
c: No country
o: Red Dwarf
objectClass: account
uid: rimmer
userPassword: {crypt}aij2kdowm.30da2
uidNumber: 1004
gidNumber: 1001
loginShell: /bin/false
homeDirectory: /home/rimmer
Most vendors use proprietary database systems internal to their LDAP
server to maintain individual records and only allow updates using API calls. A database makes records faster to access or update. The LDIF is more for human readability, and it approximates the syntax used by the LDAP software within the command operations. LDIF also allows data to be converted between LDAP servers that may use different data formats.
The basic syntax is simple, an attribute name followed by a colon and
then the attribute value (e.g., cn: Arnold Rimmer). The
DN is the first attribute beginning with a dn: followed
by the full DN attributes separated by commas (e.g.,
dn: uid=rimmer, ou=technicians, dc=reddwarf, dc=example).
Long lines are simply wrapped to the next line, with at least one blank space before the text begins. This is to simplify editing. The actual data is stored as a continuous value. Binary data, such as images, signatures, or audio is stored as base 64-encoded data which can be represented in text form.
LDAP operations
The basic update operations to a directory -- add, delete, modify, and rename -- restructure the DIT and its entries. Add and delete are fairly self-evident; they add a new entry or delete an entry based on a DN or RDN. Modify changes the list of attributes, or their values, in an existing entry. The operations rename or modify are used to either move an existing entry to a different location in the directory or to change its name. They work very much like the mv shell command in Unix.
Search and compare send a set of parameters to the server that request objects that match the operation. A fully declared search operation involves eight parameters:
- The tree or subtree you want to search
- How many levels of the tree to search
- How aliases to other parts of the tree should be followed
- The number of entries to be returned
- The time limit for the search
- Whether only the attribute types and not its values are needed
- A filter operation to be applied to the search list
- The list of attributes to be returned
The search filter maps a regular expression string to one or more
entries within the tree. There are a number of different search filter types for string, numeric, and booleans (see Table 2). For strings, you can compare attributes by existence (presence of),
lexicographic/alphabetic equality and approximation (equals to,
approximates, greater than, less than), and substring matching (substring of). Numeric values can be compared for equality (equal to, less than, greater than), and existence (presence of). Boolean operations (and, not, or) work with any data type.
Table 2. Search filter operations
Filter |
Example |
Example matches |
Approximate |
(sn~=Rimmer) |
Rimmer or variations on spelling |
Equality |
(sn=Rimmer) |
Exactly to Rimmer |
Greater than |
(sn>Rimmer) |
Any surname that alphabetically follows Rimmer |
Greater than or equal to |
(sn>=Rimmer) |
Any surname that includes or alphabetically follows Rimmer |
Less than |
(sn<Rimmer) |
Any surname that alphabetically precedes Rimmer |
Less than or equal to |
(sn<=Rimmer) |
Any surname that includes or alphabetically precedes Rimmer |
Presence |
(sn=*) |
All surnames (all entries with the sn attribute) |
Substring |
(sn=Rim*), (sn=*immer*), (sn=Rim*e*) |
Any matching string, substring, or superstring that matches Rimmer |
And |
(&(sn=Rimmer) (cn=The Git)) |
Any entry that matches both surname of Rimmer and a canonical name of The Git |
Or |
(|(sn=Rimmer) (cn=The Git)) |
Any entry that matches either surname of Rimmer or a canonical name of The Git |
Not |
(!(sn=Rimmer)) |
Any entry other than that with a surname of Rimmer |
There is no real copy operation in LDAP, since every entry has to have a unique DN. To approximate a copy, you have to search for an existing entry, then add it to a different section using the same name, or into the same section under a different name.
The LDAP session is fairly basic in nature. It begins when a client
issues a bind operation to the server. The server may require an
authentication step at this point. Once the connection
between the two parties has been established, the client can send any
number of LDAP update or interrogation commands. Each command has a
sequence number so that the client will recognize it when multiple
responses are sent. A single interrogation command, such as a search, can return one or hundreds of records, depending upon the filter operations sent. The clients sending update operations only receive an acknowledgement or an error condition from the server when the operations are complete.
Know where it's at
LDAP implements a common platform-neutral structure to information
services of the sort needed by operating systems and applications. Although similar services have existed before, none are as widely accepted or implemented across as many platforms and applications as LDAP. By combining the information from various different sources used by the operating system, such as accounting, password, and preference files, LDAP makes it easier to manage system information and to reduce the duplication of such data.
This sums up the workings of the LDAP directory system. It's a fairly
simple protocol, but has significant implications for the enterprise.
Starting from the basic concept, the directory can span hundreds of servers and millions of entries. The biggest difficulty with LDAP is creating a proper design for the contents and topology of the servers. As NetWare sysadmins will attest, there is a lot of trial-and-error involved in designing a directory for a large corporate environment. Directory services have even resulted in reorganizations of companies themselves, in order to better suit a more flowing hierarchical model. In Part 2, we'll investigate the process of designing directory services in a hope to reduce this trial-and-error process.
Resources
LDAP resources
Related reading
LinuxWorld.com
Print
Close Window