Brief survey of common directory services (Managing NFS and NIS, 2nd Edition)

Book Home

Previous

Next

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.