From http://people.netscape.com/bjm/whyLDAP.html
A System Administrator's View of LDAP
By Bruce Markey
----------------------------------------------------------------------------
----
The benefits of LDAP (Lightweight Directory Access Protocol) to developers a
nd end users have been widely touted, but in fact it's system administrators
who may reap the greatest benefits from LDAP deployment. Here in Netscape's
IS group, we've recently been using LDAP directory services on our internal
network -- which shouldn't be surprising, since Netscape's server products
and Netscape Communicator use LDAP for sharing information. In this article
I'll give a system administrator's perspective on what you'll need in order
to reap the benefits of using LDAP: a good understanding of what LDAP can an
d cannot accomplish, some familiarity with LDAP basics, and ideas on how to
make the transition to LDAP.
Why LDAP?
At a monthly meeting of Unix system administrators in Silicon Valley, LDAP w
as correctly described as a system for distributing information such as list
s of users. A concerned system administrator was quick to ask, "With all the
user lists that I manage already, why do I want to have another one?" A fai
r question, I thought, and one that hints at why system administrators shoul
d pay close attention to LDAP's evolution.
LDAP has the potential to replace existing application-specific lists and co
nsolidate information. This means that changes made on an LDAP server will t
ake effect for every directory-enabled application that uses this informatio
n. Imagine adding a variety of information about a new user through a single
interface only once, and immediately the user has a Unix account, an NT acc
ount, a mail address and aliases, membership in departmental mailing lists,
access to a restricted Web server, and inclusion in job-specific restricted
newsgroups. The user is also instantly included in the company's phone list,
mail address book, and meeting calendar system. When a user leaves, access
can be disabled for all of these services with just a single operation.
That sounds wonderful, but at the same time far-fetched. How can we expect o
perating systems and applications from different vendors to agree on one sys
tem for looking up information, and why is LDAP perceived as the key to maki
ng this possible?
First, let's look at what LDAP is and isn't. Initially developed at the Univ
ersity of Michigan, LDAP is now an Internet standard for directory services
that run over TCP/IP. One or more LDAP servers contain the data that make up
the LDAP directory tree. An LDAP client connects to an LDAP server and subm
its a query to request information or submits information to be updated. If
access rights for the client are granted, the server responds with an answer
or possibly with a referral to another LDAP server where the client can hav
e the query serviced.
An LDAP server is not simply a form of database, but a specialized server fo
r directories. A directory can be distinguished from a general-purpose datab
ase by the usage pattern. A directory contains information that is often sea
rched but rarely modified. Host names or user names, for example, are assign
ed once and then looked up thousands of times. LDAP servers are tuned for th
is type of usage, whereas relational databases are much more geared toward m
aintaining data that's constantly changing.
Another difference is that relational databases store information in rows of
tables, whereas LDAP uses object-oriented hierarchies of entries. The Domai
n Name Service (DNS) for resolving host names to IP addresses also uses a hi
erarchy. Because an LDAP directory could hold host name information, it migh
t seem that LDAP could be a replacement for DNS. However, DNS is very specia
lized, and LDAP was not designed to address the same set of problems that DN
S has been groomed for. Still, DNS maintenance can benefit from an LDAP-base
d strategy.
Being designed for this usage pattern, current directory servers with a mill
ion or more entries can respond to hundreds of search requests per second fr
om a single server. Replication is also possible, which makes LDAP very scal
able.
Reducing load on the authoritative server is not the only reason for using r
eplica servers. Many Unix networks use Network Information Service (NIS), al
so known as YP, which uses slave servers on each subnet. As with YP, putting
replicas on subnets can avoid network traffic through routers and reduce la
tency. However, unlike YP, the LDAP synchronization scheme features incremen
tal updates that can be pushed immediately to the replicas rather than perio
dically transferring all of the data. For Netscape's internal mail hubs, we
use replicas on the local host. While this really isn't necessary, it does a
llow the Netscape Messaging Server to do lookups locally with very little ov
erhead to maintain synchronized data.
LDAP Basics
Before going any further with architecture issues, let's look at how LDAP or
ganizes information. LDAP introduces a lot of new terminology, but the only
terms you need to understand to get started are entry, object class, attribu
te, and distinguished name.
An LDAP server contains entries, and each entry's type is defined by an obje
ct class. An object class defines attributes, both required and optional, as
sociated with an entry of that class. Each entry is uniquely identified by a
distinguished name, or DN. The DNs are organized in a hierarchy; each one c
onsists of the name of an entry plus a path of names tracing the entry back
to the root of the tree.
For example, given that I work at a company in the United States, the top en
try in the hierarchy for my entry has the DN "c=US". This top entry is of th
e object class country. A country entry has one required attribute, c, with
the value ofUS in this case. At the next level down in the hierarchy, an ent
ry of the object class organization has the DN "o=Netscape Communications Co
rp., c=US". The organization entry requires the attribute o, which is Netsca
pe Communications Corp. in this case. Notice that the parts of the DN are se
parated by a comma.
What we have at this point would likely be the base DN for this server. A ba
se DN defines the top of the namespace that the server is responsible for, m
uch like a DNS zone. As we add entries further down the hierarchy, the DNs b
ecome longer. Remembering a long DN is not an issue for end users, because c
lient applications will be doing the searches and then displaying the attrib
utes the user needs to see. For most applications, the full DN does not need
to be exposed to the end user.
Now that the groundwork has been laid, let's look at an entry for an individ
ual. The entry's DN is
"cn=Bruce Markey, o=Netscape Communications Corp., c=US"
This entry is of the object class inetOrgPerson, which requires a cn attribu
te (for "common name"). It also requires an sn attribute for the surname; th
is is an example of a required attribute that is not the attribute included
in the DN. The inetOrgPerson class also defines about 50 other attributes th
at can be associated with a person, such as uid, title, manager, telephoneNu
mber, pager, mail (e-mail address), and other information you would likely w
ant to associate with a person in an organization that has access to the Int
ernet. It even has the attributes jpegPhoto and audio, which are possible be
cause attribute values can be declared to be encoded into different syntaxes
, including binary data.
In order for authoritative information to be maintained, access control need
s to be imposed for privileges to read, write, search, or compare. Access co
ntrol can be done on a subtree, entry, or attribute type and granted to indi
viduals, groups, or "self" (which allows an authenticated user to access his
or her own entry). This scheme provides a great deal of flexibility. For ex
ample, you may want to only allow people in a human resources group to chang
e the title or manager attributes, allow administrative assistants to change
office location and pager number information for just their department, and
allow individuals to modify their own home phone number, license plate, and
so on.
More Than a Protocol
Understanding how to maintain the data is not enough to be able to put LDAP
to use. There are four well-defined pieces of the overall system that simpli
fy implementing LDAP: the LDAP open standard, the API, the LDIF text format
for data, and the object class definitions.
LDAP -- RFCs 1777 and 1778 define the protocol that allows clients from diff
erent developers on any platform to talk to any type of LDAP server. Many ve
ndors have announced support for LDAP. Notably, Netscape, Microsoft, and Nov
ell already offer directory-enabled servers and clients. The University of M
ichigan, where LDAP evolved, has source code for their original slapd server
and other tools available for download.
API -- One of the important factors in the success of LDAP is that developer
s should be able to make use of information from an LDAP server without havi
ng to write and debug a lot of code. A well-defined application programming
interface (API) helps make this possible. You may be familiar with SOCKS and
"socksifying" an application; with LDAP, directory enabling is a very simil
ar process. For a program to make use of directory information, you simply i
nclude the API libraries in the source directory, modify the program's code
to call the API functions at the point where the information needs to be loo
ked up, and recompile. The most recent version of sendmail already includes
the API and has options to look up information through LDAP.
LDIF -- Another piece of the puzzle that I've found to be remarkably importa
nt is the LDIF file format. This ASCII text format is used for exporting and
importing data to and from LDAP servers. This not only makes it easy to mig
rate data from one server to another but also allows you to write scripts to
create LDIF files from other data sources. You can then verify and manipula
te the LDIF file before committing the data to the server. Because command-l
ine tools like ldapsearch return data in LDIF format, you can save some or a
ll of your data to a file, make global changes, and then import the new data
back into the server.
Object classes -- One other piece that's important to portability is object
class definitions. If a client needs some attributes that aren't in the well
-known object class definitions, a new object class can be created as an ext
ension of a similar object class. The client could then work with any LDAP s
erver, as long as the server has been given this new object class definition
.
Making the Transition to LDAP
Even with a solid understanding of LDAP concepts, switching to LDAP won't ha
ppen instantly. There are two distinct ways to put information to use: one i
s to use applications that are already directory-enabled, and the other is t
o gateway the information from LDAP into a format used by existing applicati
ons.
Here at Netscape, we first used a corporate-wide phone book that was availab
le through a web page. This was the beginning of creating an authoritative l
ist of employees on our central Directory Server. Netscape Communicator now
includes a window that can do native LDAP searches. Not only can that act as
the corporate phone book, but results can be selected to automatically addr
ess e-mail messages. Once the data is being stored and updated on an LDAP se
rver, other applications can take advantage of this resource.
Many LDAP-based software distributions include command-line tools for search
ing and modifying directory information. This makes it possible to use or ma
nipulate information with simple shell scripts. There are also tools availab
le for programming in Perl, Java, C, and so on.
Let's look at Unix login information as an example of some possible transiti
on strategies. Once attributes for users are stored in a directory server, a
useful thing that can be done is to sync up user names and passwords for mu
ltiple environments. We've implemented a system in-house where Unix and NT a
ccount passwords are updated when passwords are changed through our Director
y Server interface. This not only simplifies the change for users but can re
duce the chance of having infrequently used accounts with forgotten password
s.
One of the more interesting gateways to date is ypldap by Luke Howard of Xed
oc. This is an NIS (YP) server that uses LDAP instead of files to look up it
s information. It supports passwd and group maps along with the other common
ly used YP maps. This approach allows using existing YP-based applications w
ithout needing to run a script for converting the data.
Eventually, even tools like ypldap may become unnecessary when operating sys
tems include directory-enabled /bin/login. Most Unix versions have a configu
ration file that tells the OS where to look for password information. It sho
uld be relatively easy for vendors to add LDAP as one of the choices along w
ith NIS and the local /etc/passwd file.
I hope that at this point you're thinking about installing and testing a Dir
ectory Server on your network. As you start down the path to consolidating i
nformation with LDAP, be aware that LDAP is not an all-or-nothing propositio
n. You should start with one application as a pilot project. Once you have a
uthoritative information in your Directory Server for one application, you'l
l soon see the value of phasing in other applications.
----------------------------------------------------------------------------
----
LDAP Resources
LDAP: Programming Directory-Enabled Applications with Lightweight Directory
Access Protocol by Tim Howes and Mark Smith (Macmillan Technical Publishing,
1997) is an outstanding book focusing on the API.
RFC 1777, Lightweight Directory Access Protocol, and RFC 1778, The String Re
presentation of Standard Attribute Syntaxes, contain specific information ab
out the protocol.
The University of Michigan site is a good starting point on the web for info
rmation about LDAP.
PADL Software provides information about Luke Howard's ypldap.
Netscape's web site has several articles about LDAP and information about pr
oducts that incorporate LDAP, including:
The introductory View Source article Directories and LDAP: Universal Access
to Directory Information
The white paper An Internet Approach to Directories
A starting point for information about Netscape Directory Server, which feat
ures web-based administration and documentation
The ability to download and test drive the Directory Server
----------------------------------------------------------------------------
----
Bruce Markey is a Senior System Administrator in the Server Operations group
at Netscape. He began using UNIX 7th Edition in the early 1980s and has sin
ce supported more than 20 Unix variants. In 1990 he came to Silicon Valley,
where he worked as a system administrator for a series of successful startup
software companies. Since June 1995 Bruce has worked in a variety of server
product support roles for Netscape.
(7:98)
----------------------------------------------------------------------------
----
DevEdge Online FAQ
Developer Response Center
Join DevEdge Program Copyright ? 1998 Netscape Communications Corporation.
This site powered by: Netscape Enterprise Server and Netscape Publishing Sys
tem 1.6.
Posts
