Click on our Sponsors to help Support SunWorld
Connectivity by Rawn Shah

Life after DNS

Lightweight Directory Access Protocol
promises serious, nimble directory service

SunWorld
October  1996
[Next story]
[Table of Contents]
[Search]
Subscribe to SunWorld, it's free!
Abstract
The Lightweight Directory Access Protocol (LDAP) may prove to be the glue that unites various directories in a usable fashion. In this article we discuss how LDAP compares to DNS, X.500, and MAPI. (1,800 words)


Mail this
article to
a friend

To know one's place in the world is a much underrated ability. A sense of direction and purpose provides each of us with an identity private to ourselves and presentable to others. In the computer realm, a good sense of self-identity is not just healthy emotionally, but a necessity. Without the ability to locate resources or files on our computers, most of us would amass piles of Post-it notes indicating where we put our files.

In the last two months I've discussed WebNFS and the Common Internet File System (see the Resources section below for the URLs). These two jewels make it possible to access files across the vast expanse of a WAN in a manner more efficient than FTP and HTTP. The goal of WebNFS and CIFS is to make access to files not just easier but much more efficient for the client, server, and network. Both protocols would find good use in your own LAN or WAN.

Network file access is dependent on a much more basic issue: unique identification of files, resources, and objects. Maintaining a system of identification is difficult. The system must identify each and every object in the computer realm and receive wide support from users and vendors. The ISO made a stab at the problem with X.500, a unified global directory for any type of object. With a respectful bow to X.500, the Internet community knighted one of its own developments, the Lightweight Directory Access Protocol (LDAP), to reign over the directory realm.

What's in a name?
We have all seen naming systems. In natural sciences, organisms are classified by kingdom, phylum, class, order, family, genus, and species. Using this system malacologists can distinguish banana slugs (Ariolimax dolichophallus) from their more pedestrian brethren. In the computer trade we use several naming systems, including:

Why do we need another one?

The sad and simple answer is that none of the systems mentioned is proper or satisfactory in the Internet arena. DNS is magical in its ability to resolve hostnames and addresses for the millions of computers connected to the Internet. But DNS is limited to only that. X.500 is on the other end of the spectrum, it can describe any single object in the entire world, but it's also monstrously large with staggering overhead, and requires use of the OSI protocols to function adequately. The others are proprietary and do not support TCP/IP natively.

Academicians at the University of Michigan and bright minds at top vendors agreed to sculpt the well-endowed X.500 Directory Access Protocol (DAP) into a simple, efficient, and native TCP/IP standard. The result is LDAP, which stands for Lightweight Directory Access Protocol. Please refer to LDAP as "RFC 1777" when spouting Internet jargon.

Advertisements

Name thyself!
Our need to identify users and access rights is the big idea behind LDAP. Netscape adopted LDAP early, and added the functionality to the server sold with its Enterprise Suite. With such a system, we can create identities for users of any operating system. Traditionally, vendors offered different ways to identify users, ranging from the System User Authorization File (SYSUAF) of OpenVMS, to the simpler /etc/passwd and /etc/group in Unix.

The growth of the intranet and the use of the Web as a shared development and communications tool has further pronounced the need for a standard way of giving the right people access to the information they need. Users steering browsers perched on different operating systems need to access one shared Web server and still maintain their identities. Although it is possible to create a login-based system in the Web server itself, there has until recently been very little in the manner of unity or security.

LDAP solves this issue and several others, including identifying network resources (such as printers and shared drives), identifying searchable catalogs, and acting as a common repository for secure public key certificates.

Works
An LDAP server sits on TCP port 389 and serves requests to any LDAP-compliant client. Within the server, each entry is kept as a name-value pair. A group of specific entries such as a user's first and last names, telephone number, address, etc. combine to form a distinguished name (DN). Although mostly stored as text strings, the server can also store other non-text data as well. These values are defined in the sibling Internet RFC 1778.

In addition to simple combinations with DNS, there is a hierarchical structure to each directory. This is similar to the Unix file tree with a root object followed by components indicating the path. Following the full path will give you a description of the object for which you are looking. For example, say you wanted to find the information about Goofy who works in the Magic Kingdom's marketing department:

[Example of distinguished name (DN)]

Following the path to identification, each node represents a domain. The letter c identifies the country; o indicates the organization; and ou, the organizational unit. Finally, each person has a Canonical Name (CNAME) followed by other particulars. The full DN of this character is the following: 

	c=US o=Magic Kingdom ou=Marketing 
cn=Goofy mail=goofy@magic.dom fax=(810) 555-5384

This is a simplified example. According to the X.500 standard and LDAP, there may be additional levels in between.

Just like in the Unix filesystem, you can have Relative Distinguished Names (RDNs). For example, within the domain c=US, everything else following the above full DN is relative. (There could be another organization with the same name in the domain c=UK.) Within the organization, there are many RDNs for each employee.

If it looks too detailed for humans to remember, don't worry. Most of these details are taken care of automatically. For the most part, users will simply type in a CNAME and the software figures out the proper DN in context.

This information can be put to a variety of uses. For example, you can make an X.400-like e-mail address using this unique identification system. Your word processor can use the information to create a mailing list that merges with a form letter. With new computer telephony products arising, you might even use this with Caller ID.

Security
The question remains: just how secure is it? With all this information kept on an Internet-accessible server, surely there has to be strict security that prevents users from mucking around in areas where they are not supposed to be.

LDAP allows access control lists per DN and path, meaning that you can specify a list of users who have the following different levels of access to the information:

Some of these operations may require others, but because most are standalone you can assign very specific control to individual software, users, or organizations.

Comp time
LDAP competes with several protocols of similar nature. For example, the Internet WHOIS database is a common identification mechanism for users. The proposal for WHOIS++, which has been in the works for quite a time, has been adopted by some, but does not enjoy the support of its predecessor.

Similarly, LDAP acts like DNS in its ability to resolve network names and addresses of hosts. Yet it goes a step further by describing the actual type of resource. DNS can affix names to resources through the CNAME identifier for each computer. But there is little standardized about its use.

Access Control remains a thorn in the side of the industry. Few vendors agree to the format of access rights. Why? Because vendors consider their filesystems crown jewels -- technologies too expensive or politically dangerous to change. For example, Sun's NIS and NIS+ security and access system differs from the DCE security mechanism. Sun and DCE supporters believe that theirs is better and see no reason for unity or compromise.

Replication is one useful feature of any database or directory structure and allows for more efficient access in localized areas as well as providing a basic measure of fault tolerance. We can certainly find replication in use in NDS and StreetTalk, but it isn't supported in many other directory systems.

LDAP is a rather new system and so far has only been released by a few vendors. Products based on LDAP aim to replace proprietary directory systems like MAPI and most probably create new markets for software with their integration with the Internet. Most of the top Unix vendors certainly have some interest in this. IBM, HP, and Sun have indicated that they will be releasing LDAP servers. Microsoft is hesitant to accept LDAP, but will probably do so. Netscape, of course, already has an LDAP server with its product line. If you wish to experiment with LDAP, you may want to take a look at the freeware Unix version from the University of Michigan.


Click on our Sponsors to help Support SunWorld

Resources

About the author
Rawn Shah is vice president of RTD Systems & Networking Inc., a Tucson, AZ-based network consultancy and integrator. Reach Rawn at rawn.shah@sunworld.com.

What did you think of this article?
-Very worth reading
-Worth reading
-Not worth reading
 -Too long
-Just right
-Too short
 -Too technical
-Just right
-Not technical enough
 
 
 
    

SunWorld
[Table of Contents]
Subscribe to SunWorld, it's free! 		[Search]
Feedback 		[Next story]
Sun's Site

[(c) Copyright Web Publishing Inc., and IDG Communication company]

If you have technical problems with this magazine, contact webmaster@sunworld.com

URL: http://www.sunworld.com/swol-10-1996/swol-10-connectivity.html
Last modified: