 | |  |
2.2. Brief survey of common directory services
There are numerous different directory services. Here we will discuss some of
the commonly used ones.
2.2.1. Directory Name Service (DNS)
The roots of DNS are in the early (pre-Web) days of the Internet.
DNS was developed to provide hostname and address resolution. Before
DNS existed, the authorities for the Internet maintained a global
flat text file of the mappings from hostname to IP address in a file
called hosts.txt, which was then made available
for all the nodes on the Internet to download via a program
called
gettable. This is analogous to the telephone
company giving you an updated telephone book periodically. Systems
like Unix would convert the file into
/etc/hosts.
This hosts.txt system worked fine for the
Internet when it had only thousands of hosts. But when it reached
tens of thousands of hosts, it wasn't practical, especially
over the slow links available in the late 1980s. What was needed was
a way to decentralize the process of looking up hostnames and
addresses. The Internet was separated into domains, and each domain
was left to identify its own authoritative server for hostnames and
addresses within its domain. The only thing that needed to be
maintained in a global database was the list of domain names, and the
servers for that domain. Returning to the telephone directory
analogy, when you live in one area code of the United States, and
want to get directory information for another area code, you can
prefix the area code to the number 555-1212 to get the appropriate
directory service operator.
By assigning authority for a domain's directory information to
each domain, DNS can be described as being hierarchical. Similarly,
the United States telephone system assigns authority for a given area
code's directory information to one pool of directory service
operators that answer the 555-1212 number. DNS also lets domains
within subdomains further delegate authority, and subdomains in turn.
For example, in DNS there is a top-level domain called
".com" that assigns authority for administering
sun.com and oreilly.com to
DNS servers that the owners of sun.com and oreilly.com each
designate. Within sun.com, there are several
subdomains, such as eng.sun.com, and
east.sun.com. Within
eng.sun.com, there might be a
compiler.eng.sun.com,
sunos.eng.sun.com,
cde.eng.sun.com. Thus DNS is a multilevel
hierarchy, whereas the United States telephone directory service has
but two levels of hierarchy.
DNS has stood the test of time. In 1993, a memorandum (RFC 1401) was
written by the chair of the Internet Architecture Board that noted
that the transition from hosts.txt to DNS was largely complete. This
is fortuitous, as the World Wide Web was about to explode from tens
of thousands of hosts to millions. DNS proved capable of handling
that
explosion.
2.2.2. Network Information Service (NIS)
NIS was developed by Sun Microsystems in the mid-1980s
to solve a problem that until then had no solution in the Unix world.
Let's return to the telephone directory service concept. One
nice thing about calling your telephone company's directory
service is that the operator (the server) is more apt to have
up-to-date information than you would. Your telephone book is
replaced once a year, whereas the server's information is
updated more frequently, perhaps instantly with each new telephone
number assignment and de-assignment. When networking was added to
Unix systems, system administrators very quickly ran into
difficulties keeping files like /etc/hosts
(holds hostname to host address mappings) and
/ etc/passwd (holds username, user identifier,
password). If a system administrator had 100 systems, then adding a
host to a network or a user to the organization meant the tedium of
updating the /etc/hosts or
/etc/passwd files on all 100 systems. NIS,
originally called the Yellow Pages or YP, was invented to simplify
management of these files by changing the underlying programming
interfaces, such as gethostbyname( ) and
getpwnam( ), to use NIS client libraries.
While DNS was being developed around the time NIS was, DNS was mostly
concerned with the directory of hostnames and addresses, whereas NIS
went beyond that. In addition, DNS was designed so that a host in one
domain could access information from other domains, whereas NIS
shared the limitations of the early Internet's
hosts.txt file: flat and not very dynamic.
We will go into much more detail on how NIS operates in Chapter 3, "Network Information Service Operation".
2.2.3. NIS+
In 1992, Sun Microsystems released NIS+ with Solaris 2.0.
Despite its name, NIS+ was more different than it was similar to NIS.
NIS+ was developed to address several deficiencies in NIS:
- Hierarchical operation
- While NIS was designed to be split into unique domains,
there was no simple way for a client in one domain to get directory
information from another domain. NIS+ addressed this by supporting a
multilevel hierarchy in a manner similar to DNS.
- Security
- There are really two issues here.
First is that some kinds of directory
information need to be kept more secure than others, such as a
directory containing credit card numbers. The directory server needs
to know who is accessing the data, and properly authenticate the
client. Second, the client needs to be certain that the server is the
true authority for the service. An attacker in the middle between the
client and real server could masquerade as the server and return
bogus information. NIS+ deals with both these issues by supporting
mutual authentication: the client and server authenticate each other,
via a secure form of RPC known as RPC/dh, which is described in Chapter 12, "Network Security".
- Updates
- Updating a NIS database and propagating the changes is a cumbersome
process. Only the system administrator can make updates (with few
exceptions), and the changes must be pushed to each replica server by
pushing the entire database, even if only one record changes. NIS+
supports the ability to allow users to update directory entries they
have access rights to. For example, a user changes the name that
appears in the password database, which might be necessary upon a
status change like a new job title, or a new surname as a result of a
marriage or divorce. NIS+ servers have the capability to accept
incremental updates, which allows the updates to be more efficiently
distributed.
2.2.4. X.500
Around the same time DNS and NIS were being
designed
and deployed, the International Standards Organization (ISO) started
meeting to define an ISO standard directory, called X.500. X.500
shares DNS's and NIS+'s attributes for hierarchical
operation, and NIS+'s attributes for security and simple
update. X.500 differs from DNS, NIS, and NIS+ in the following ways:
- X.500 is very explicit about what each level of the hierarchy of a
domain name looks like. If you see a domain name like:
chicago.manufacturing.widget.com
it could easily be a DNS, NIS, or NIS+ name, and it could very well
be for a host or a domain. Moreover, while it might seem like
chicago.manufacturing.widget.com refers to a
subdomain of hosts located in the city of Chicago, assigned to
Widget, Inc.'s manufacturing division, it could just as easily
refer to a hand held computer on space station Alpha. This ambiguity
is a concern to some folks. Hence, X.500 explicitly identifies what
each level of hierarchy means. For example, the X.500 distinguished
name corresponding to DNS style
chicago.manufacturing.widget.com name would be:
{ Country = US, Orglanization = Widget, Inc., Organizational Unit =
Manufacturing, Location = Chicago }
- X.500 supports the notion of schema. A
schema is
a set of rules for what can be stored in a database. Defining a
directory schema is useful when performing search operations on a
directory. Say a database includes the hire dates of employees, and
you want to search for all employees hired between a particular range
of dates. Because the X.500 directory is "aware" that the
field being searched is a date, it is possible to let the directory
server do all the work of finding the matches. With DNS, NIS, and
NIS+, you would be compelled to read every directory entry from the
server, and perform the operation on the client, because the server
treats the information opaquely. The X.500 way saves network
bandwidth.
For many common databases, X.500 is overkill, but there are
situations where having an X.500 schema is handy. Say you want to
find all the hosts that are in the 192.1.1 network. If you defined
X.500's equivalent to the hosts database with a schema that had
substring matching rules, this would be easy and efficient.
2.2.5. Lightweight Directory Access Protocol (LDAP)
X.500 has a protocol called the Directory Access Protocol (DAP) to
allow
clients to access X.500 servers. DAP was
designed to operate over ISO's Open Systems Interconnect (OSI)
transport and network protocols. Once upon a time,
people believed that TCP/IP would wither away and be replaced by OSI.
As it turned out, too many people had deployed TCP/IP-based networks,
and they saw no compelling reason to switch to OSI. Despite OSI
mandates by most governments in the developed world, the Internet
transport and network protocols persisted, and it was obvious by
1994, if not earlier, that the OSI transport and network was dead.
However, as discussed earlier, X.500 has some extremely attractive
properties for a directory, but it comes with the baggage of OSI
transport and complex ASN.1 encoding. The Lightweight Directory
Access Protocol (LDAP) was invented to allow clients using TCP/IP and
simpler encoding schemes, to take advantage of the richness of X.500
directory service.
Another difference between LDAP and DAP is that LDAP is under the
control of the Internet Engineering Task Force (IETF), the same
organization that produced the standards
behind the Internet. Whether intended or not, the effect is to get
IETF to buy into X.500, whereas previously IETF had no control over
OSI transport and network, and so it was much harder (and eventually
impossible) to get IETF to accept OSI transport and network.
LDAP specifies lots of different security flavors, including ones
based on public key certificates and Kerberos V5.
At the time this book was written, LDAP was only starting to be
integrated with operating systems. Windows 2000 is the first such
offering from Microsoft. Solaris 8 includes a fully integrated LDAP
client, but no server.
2.2.6. NT Domain
NT Domain is the directory service
used in
Windows NT. It was introduced by Microsoft in 1987 and was called Lan
Manager at the time. NT Domain is intended to administer users,
groups, printers, and hosts in a Windows environment. NT Domain now
supports multilevel hierarchies, but requires a bilateral trust
relationship between each domain. So if there are N domains in an
organization, N * (N - 1) relationships need to be set up. NT Domain
supports slightly better security than NIS. Perhaps the biggest issue
with NT Domain is that it is an undocumented proprietary protocol,
making it difficult for Windows and non-Windows systems to share NT
Domain directory information.
Microsoft is moving away from NT Domain in favor of Active Directory,
which is a derivation of the LDAP protocol and X.500.
While NT Domain is not supported on Solaris and most other Unix
systems, if you have a mixed environment, you'll probably
run into
it.
|  | | | 2. Introduction to Directory Services |  | 2.3. Name service switch |
|
|
