An Introduction to LDAP
Pages: 1, 2
Why should I trust LDAP to unify my directories?
LDAP was specifically designed to solve the problems caused by the proliferation of directories across a network, and there are seven aspects of its current implementation that give it that ability.
Because LDAP was designed to be a general-purpose directory, it had to be extensible. It uses an object-oriented, inheritance-based schema definition, which provides for easy extension to any reasonable use. There is a base schema as part of the LDAP specification, and there are other de facto standards for various services. However, it is expected that most developers will extend the base schemas.
One of the most important aspects of LDAP development, and that which caused it to be adopted in lieu of DAP, is that it is a simple protocol and is relatively simple to implement and work with. This is borne out by the fact that LDAP is supported by most major programming languages, including C, Java, and Perl, and either is supported or will be supported by most major operating systems, including Solaris, GNU/Linux, Microsoft Windows, and Mac OS.
Using data replication, it is possible to replicate all or part of an LDAP directory to physically separate locations, which allows for highly-available data and puts the data as close as necessary to the client. Using referrals, data mastery of portions of the directory can be distributed across different LDAP servers, thus allowing portions of an enterprise or project to have control over necessary data while maintaining a single authority over each piece of data.
A large focus of LDAP development has been security, with version 3 of the LDAP protocol bringing significant improvements.
There are three basic aspects of securing the information in a directory: access, authentication, and authorization (AAA, or Triple-A). Access is the ability to connect to a service and can be restricted based on details like time of day or IP address, authentication is the ability to prove to the service that a client is a valid user, and authorization is the service providing or denying specific rights or capabilities to the client.
Unfortunately, the syntax of ACLs is not yet part of the LDAP specification. It seems likely that Netscape's implementation of ACLs will be accepted as the standard, but that has not happened yet and different LDAP servers may implement ACLs in different ways. However, this should not affect development or functioning of the client.
For secure access, LDAP supports Transport Layer Security (TLS), which can encrypt all communication between the client and server. For authentication, LDAP supports Simple Authentication and Security Layer (SASL), which allows the client and server to negotiate a (hopefully secure) authentication method.
TLS and SASL provide encryption capabilities but not control over access and authentication. LDAP actually provides the ability to control all three aspects of AAA through Access Control Lists (ACLs). ACLs can be used to grant access based on many different factors. They can be used to force specific types of authentication, and once the client is fully authenticated as a valid user, ACLs are used to authorize the user.
Because LDAP is an open standard maintained by the IETF, it can be used by any developers, companies, or administrators without fear of being tied to proprietary protocols or specific vendors, and allows the choice of implementation to be based on project details rather than interoperability concerns. This also means that LDAP can progress according to the needs of the people who use it, rather than a corporation concentrating on profits or marketshare.
Server feature and schema requests
The LDAP specification states that LDAP clients can request the entire feature list and data schema from any LDAP server, thus allowing the client to vary its functionality according to that of the server, which should provide greater interoperability across different implementations and different versions of LDAP.
LDAP uses UTF-8 for internal string representations. This allows LDAP to store and manipulate any language of the world.
This is not an exhaustive list of all of the features of LDAP, but it details some of the most important aspects of the protocol. In fact, one of the reasons that LDAP is being adopted now is only marginally related to LDAP itself: The computer industry, especially in the area of network management, is ready for enterprise-wide directories. This is evidenced by them cropping up everywhere, from servers such as Netscape's Directory Server and Microsoft's Active Directory to clients such as email programs and operating systems all the way to standards specifications such as the Directory Enabled Networks (DEN) initiative.
I'm sold. How can I get some?
Unfortunately, LDAP isn't quite the panacea we all dream of today. The main problem is that it isn't as supported as it could be. For instance, Sun's Solaris operating system provides support for LDAP as its naming service, but that support doesn't include any type of encryption, which is basically unacceptable. There are also still a surprising number of vendors and programs that don't provide support where they should, and many technology decision-makers either don't know what LDAP is or don't think it matters to them.
This points to another problem with the state of LDAP today: There is not much in the way of lay-person documentation or support. Yes, you can read the RFCs and source code, but high-level descriptions of what LDAP is and how it might be useful, now and in the future, are sadly lacking, especially in succinct formats (the best LDAP book available today is almost 800 pages long). Even for the applications that currently support LDAP, it is usually far more difficult to get them to work than it should be, which is causing a slow adoption of LDAP.
Then why would I even bother?
Although it is easy to take a gloomy view on the future of LDAP -- and certainly its present -- the fact is that more vendors, applications, languages, and operating systems are supporting LDAP, and more organizations are depending on it for management of key information. LDAP directories are great for organizations that do a lot of web development or custom application development. Although the industry support isn't the best right now, most vendors either currently partially or fully support LDAP or are talking about doing so. And frankly, LDAP really is a simple protocol and has APIs for any language. If you are developing web applications, or just need a good directory to store information in, chances are you should at least look at LDAP -- you may like what you find.
So now is the time to begin learning about LDAP and trying to understand what role it can play in what you do, whether you function as a developer, administrator, decision-maker, or all three. The longer it takes our industry to fully support LDAP as a standard for directories, the more time we all have to spend maintaining redundant and often inadequate information stores and methods of interacting with them.
Where we go from here
Next time we'll cover the LDAP protocol in more depth, and begin to develop our LDAP expertise by building a basic LDAP directory.
Luke A. Kanies is an independent consultant and researcher specializing in Unix automation and configuration management.
Return to ONLamp.com.