Linux Server Security (2nd Edition( [Electronic resources] نسخه متنی

7.1. LDAP Basics

In a nutshell, LDAP
provides directory services: a centralized database of essential
information about the people, groups, and other entities that compose
an organization. Since every organization's
structure and its precise definition of "essential
information" may be different, a directory service
must be highly flexible and customizable: it's
therefore an inherently complex undertaking.

7.1.1. Directory-Services Protocols

X.500, CCIT's protocol for
directory services, was designed to
provide large-scale directory services for very large and complex
organizations. Accordingly, X.500 is itself a large and complex
protocol, so much so that a
"lightweight" version of it was
created: the Lightweight Directory
Access Protocol (LDAP). LDAP, described in RFCs 1777 and 2251, is
essentially a subset of the X.500 protocol, and it's
been far more widely implemented than X.500 itself.

X.500 and LDAP are open protocols, like TCP/IP: neither is a
standalone product. A protocol has to be implemented in some sort of
software, such as a kernel module, a server daemon, or a client
program. Also like TCP/IP, not all implementations of LDAP are alike,
or even completely interoperable (without modification). The
particular LDAP implementation we'll cover here is
OpenLDAP, but you should be aware that other software products
provide alternative implementations. These include Netscape Directory
Server, Sun ONE Directory Server, and even, in a limited way,
Microsoft Active Directory (in Windows 2000 Server).

Luckily, LDAP is designed to be extensible: creating an LDAP database
that is compatible with different LDAP implementations is usually a
simple matter of adjusting the database's record
formats (or schema, which we'll
discuss shortly). Therefore it's no problem to run
an OpenLDAP server on a Linux system
that can provide address-book functionality to users running Netscape
Communicator or Microsoft Outlook.

7.1.2. Hierarchies and Naming Conventions

The whole point of a directory service
is to provide a "roadmap" of your
organization: an abstract data model that correlates closely to the
"shape" and structure of that which
it describes. For many organizations, it makes sense for their LDAP
database to be structured like their organization chart. For others,
it makes more sense for their LDAP database to correlate with the
geographical locations of their organization's
various offices and other buildings (especially if their org chart
changes frequently). And for still others, a perfectly flat naming
structure is most appropriate.

The most visible manifestation of an LDAP database's
structure is in its naming convention, so much so that the terms
naming convention and database
structure are practically interchangeable when
you're talking about LDAP. Thus, before I give some
examples of LDAP database setups, let's discuss LDAP
naming conventions.

You're probably already familiar with the concept of
hierarchical naming conventions thanks to Internet
Domain Name Service (DNS), in
which each organization on the Internet belongs to some
top-level domain such as .org, .com, .info,
etc., but with its own unique domain
name (e.g., salesweasel@marketing.).

Conceptually, entity names in LDAP and X.500 are built
the same way. The full name of an LDAP/X.500 entity, called its
distinguished name (or dn),
is similarly constructed from a unique combination of an entity name
plus shared organization-name elements. For example, my own
distinguished name in an LDAP database might be expressed as
cn=Mick Bauer,dc=wiremonkeys,dc=org.
(cn is short for common
name, which is the name my entry is indexed by, and
dc is short for domain
component.) Technically, my entity name (cn=Mick Bauer) need
not be totally unique: if there are other people in the directory
named Mick Bauer, there's no problem so long as each
of us has a unique dnthat is, so long as
each one of our "full" LDAP names
is unique. In actual practice, it's a lot easier to
ensure unique dns by enforcing unique entity
names (cns, uids, etc.), as
we'll see shortly.

There are two common ways of organizing names (and thus of
representing organizational structures) in X.500/LDAP, one of which
is simply a fancy way of notating DNS names, and the other of which,
the more traditional X.500 convention, is based on geographical
locations. The "traditional X.500"
equivalent of the distinguished name in the previous paragraph might
be cn=Mick Bauer,
o=Wiremonkeys, l=St.
Paul, st=MN, c=US.

In my examples, I'm sticking to DNS-style names due
to this newer convention's popularity and due to its
similarity (conceptually if not cosmetically) to the more-familiar
Internet DNS. (I also much prefer this convention personally.) But
you should keep in mind two things.

First, unless you intend to use LDAP for DNS (which is way beyond the scope of
this book), there technically isn't any relationship
between the naming convention you choose to use in your
organization's LDAP database and your local DNS;
while I recommend that you make them consistent for
sanity's sake, LDAP and DNS are technically two
separate things. So if, for example, your
organization's Internet domain name is
plizbiscuitsmith.info but
you've got some reason to make your LDAP suffix
plizbis.com instead (or more precisely
dc=plizbis,dc=com), you're
perfectly free to do so.

Second, regardless of which naming convention you choose (even if you
make up your own), note that in LDAP you must use naming tags and
commas rather than simple dots to delineate your name. For example,
if my Internet domain name is wiremonkeys.org,
my equivalent LDAP domain name will be
dc=wiremonkeys,dc=org.

So, let's look at a couple of example LDAP
structures, complete with the obligatory line diagrams. Suppose
Wiremonkeys' org-chart^[1] looks
something like Figure 7-1.

^[1] Purely
hypothetically, that is. Wiremonkeys would be a poor excuse for an
underground organization indeed, if I went around publishing its
real org chart.

One way I could structure my LDAP database would be to have a
root of dc=wiremonkeys,dc=org and two
Organizational Units, or ous, of
ou=Value-Subtracted Services and ou=Dept.
of Getting Stuff Done. transposed onto our org chart, such
an LDAP structure would look like Figure 7-2.

There are two main advantages of using an "org-chart-mirroring"
LDAP structure like the one in Figure 7-2:
it's intuitive, and it's less
likely to result in name collisions than with other structures,
assuming your chances of having a John Smith in more than one
ou are small.

However, the larger your organization, the more foolish that
assumption is. Even though the
"individual" part of a
dn (e.g., the cn)
doesn't have to be unique so long as the total
dn is, in actual practice, it can be difficult to
ensure dn uniqueness without enforcing
individual-name completeness. The typical medium-to-large
organization has several John Smiths, and the chances of all of them
being in different departments, having different middle initials,
etc., is inversely proportional to the size of the organization.

In fact, some LDAP administrators eschew using the customary
Common Name (cn)
attribute at all, in favor of userID
(uid).^[2] Whereas cn is meant to designate
people's "human"
names, uid is equivalent to operating system
usernames, which are unique by definition (across a given system).
Put another way, if you use cn, people assume they
get to use their real name, even if it isn't unique
within your organization, but uid
doesn't carry that expectation/baggage, so using
uid rather than cn may save you
headaches.

^[2] For people, that is. With
LDAP entries for devices or buildings, the LDAP administrator
typically has much greater latitude in choosing
cns, so as Figure 7-3 shows,
it's still customary to use the
cn attribute for non-humans even when it
isn't feasible to use it for people.

The org-chart-mirroring LDAP structure's
intuitiveness notwithstanding, it may not have anything to do with
how you wish to use LDAP. Suppose, for example, that your LDAP
database is going to contain information not only about users, but
also about computers on your network. In that case, a structure more
like the one in Figure 7-3 might be in order:

Figure 7-3. Another LDAP directory structure

This structure has the advantage of simplicity: all people are in one
big group. But it also has a performance disadvantage, since, um, all
people are in one big group. Without going into the technical
reasons, I must point out that if you wish to use this sort of a
structure with a large number of users, you'll
greatly enhance your LDAP server's performance by
splitting your "people"
ou into
"sub-OUs"i.e., by
combining the structures in Figures Figure 7-2 and Figure 7-3 into
something like Figure 7-4.

These are just a few examples of LDAP database structures. Your only
real limits, here, are your imagination and your stomach for hacking
LDAP schema. (More on schema hacking shortly.)