Part 1: A look at LDAP's capabilities and shortcomings
As an enterprise network expands from a file-and-print platform to a
platform that includes email systems, databases, Web servers, and other
applications and services, the need for a universal directory service becomes
increasingly apparent. The big three in the networking industry--Novell,
Netscape, and Microsoft--are trying to meet this need by developing the
definitive directory service solution. Although their solutions are in different
stages of development and use different methodologies, all three have committed
to using the Lightweight Directory Access Protocol (LDAP) in their directory
service products.
How Novell, Microsoft, and Netscape are using LDAP in their directory
service products will be the focus of the second part of this two-part article.
But before you look at how the big three are using LDAP, you first need to
understand LDAP's function, ancestry, birth, and evolution.
Why You Need LDAP
In a typical business network, employees need access to different services
and applications, such as a network drive (such as a Windows NT domain),
printers, an email system (such as Lotus Notes), and NetWare servers. So even in
a basic network, employees need access to several protected services on several
platforms. Therefore, businesses need a single directory service that can
provide authenticated access to all of these resources. This directory service
needs to do much more than provide usernames and passwords. It needs to
effectively store many different types of data (such as client contact
information, application configuration data, and personal documents) in a
central location. The directory service also needs to give employees the ability
to access that database from any workstation on the network or from a remote
location.
The main obstacle to developing such a directory service is that many
business network services and applications have proprietary user directories.
Because the data in proprietary directories cannot be applied to other
applications, network administrators must create separate accounts for the
various services and applications. Creating separate accounts not only generates
additional work, but also makes the task of changing passwords a nightmare.
To create a single user account that provides access to services, file
servers, databases, and other applications, you need a communications link
between the directory service and proprietary applications. LDAP provides this
link.
Meet LDAP's Ancestors
Researchers at the University of Michigan, with support from the National
Science Foundation, originally developed LDAP as a simplified means for clients
to access X.500 directory servers. X.500 is the International Telecommunications
Union (ITU) standard that defines the basic structure and functionality of a
directory service model. According to X.500, a directory service includes five
elements.
1. A directory service has a model that defines the basic structure
in which information is stored. A directory service consists of entries,
attributes, and values.
Entries represent elements in the directory service. For example, if a
directory service has 20 network users, 2 directory shares, and a shared
printer, the model would include one entry for each element, giving a total of
23 entries.
Each entry contains attributes. Attributes represent the properties that
the directory service needs to classify the entry. For example, the attributes
for the entry of network user might be the user surname and the user email
address.
Each attribute contains values. Values are the representation of
attributes. For example, the value for the attribute of user email address might
be jsmith@mycorp.com.
2. A directory service has a tree-like hierarchy, called a
directory information tree. The DIT stores the directory's entries and
uses namespaces to uniquely identify every entry's exact place in the tree. At
the top of the tree, you use geographical constructs (i.e., two-letter country
identifiers) to determine the hierarchy of entries. As you proceed downward, you
use more arbitrary organizational constructs (e.g., departments) to determine
the hierarchy of entries. An entry's distinguished name (DN) traces the entry's
path in the tree, much like a pathname defines the location of a file in a file
system tree. (To see an illustration of a DIT and a DN, see "How
to Name and Place Objects in the Directory Information Tree.")