Understanding Legacy Naming Services

Network Information Services (NIS and NIS+) have served Sun customers well over the past years , but with the competitive landscape constantly changing, the evolution of technology, and heightened security concerns, a case can be made that legacy naming services are becoming outdated .

To understand why, you need to understand why naming services evolved the way they did. The next section presents a short history of NIS and NIS+ and the environments in which they were designed to operate . It is not meant to be comprehensive, but rather to highlight key points and illustrate the advantages that exist in the directory services available today.

Evolution of NIS

NIS, or Yellow Pages as it was originally called, was first introduced by Sun Microsystems, Inc. in 1985. It provided a centralized naming service that contained information about hosts on the network, users, groups, and other network related information. Centralized storage of this data was necessary due to a shift in the computing model as the timesharing of a single large computer was being replaced with separate, smaller, distributed computers.

Each of these smaller computers, or workstations, required access to information about network resources and users permitted access to them. The Berkeley Software Distribution (BSD) version of UNIX , the basis for Sun's first operating system, had not provided a naming service, relying on the propagation of text files to all systems instead. This method became very cumbersome to administer as the number of workstations attached to a network began to grow.

To promote interoperability between heterogeneous systems, Sun published the Open Network Computing (ONC) specification. The ONC specification provides a means for any vendor to implement NIS. Over 100 vendors adopted ONC, making it a huge success.

The basic premise of NIS is to store naming data in binary files that contain key-value pairs. These binary files, called DBM files, are maintained on servers that are searched by clients specifying a key, and in return, receive the corresponding value. For example, on a client the login process specifies a user 's name as a key to retrieve the corresponding password entry from the server.

The collection of computers that accessed the same NIS service were grouped in an NIS domain. The NIS domain generally only included systems located in close physical proximity. A domain consists of one master NIS server and one or more slave NIS servers. An NIS-specific protocol is used to propagate updated data from the master server to the slave servers.

Management of NIS information was performed by local system administrators who devised their own naming conventions for hosts, users, and groups. This was not an issue at the time, because the interaction of computers located at different locations was limited.

Clients interact with NIS servers by first binding to an NIS server. The bind operation takes place when the client boots, sending a broadcast packet and waiting for an NIS server to respond. That server is then used for all subsequent name service requests , unless the server fails to respond to a request. If that happens, the client rebinds to another server. The broadcast bind method was used in part for load balancing and for failover. Load balancing was achieved, in theory, because the client binds to the least busy server.

No client authentication is required with NIS. The client simply needs to have a domain name variable defined, and broadcast that name over the subnet on which it resides. If the name matches the domain the NIS server is serving, the bind operation is successful.

The simplicity of NIS made it very attractive, and it was widely deployed. Enhancements were made along the way to overcome some deficiencies. An alternative to the broadcast method was introduced which provided the means of specifying a list of NIS servers on the client. This enhancement allows a client to reach servers beyond their local subnet, but requires that clients know the addresses of such servers. Another added feature provides the ability for an NIS server to maintain a list of trusted clients that is used to accept or reject bind requests based on the IP address of the client. Although these enhancements were made, the basic structure of NIS has remained the same over the years.

Evolution of NIS+

Because of the deficiencies in NIS, a new name service called NIS+ was introduced. In retrospect, NIS+ was ahead of its time and was probably too aggressive in its implementation. For various reasons, it was not nearly as widely adopted as NIS. However, it did introduce some interesting concepts.

NIS+ was designed to replace NIS by providing a hierarchal structure that could span an entire enterprise, provide tighter security, and offer a more scalable replication model. The data structure used to store information was improved so it could be accessed by rows and columns , eliminating the need to store the same data in different maps as key-value pairs. Hierarchal trust relationships between domains and subdomains can be established, allowing administrative span of control to be tailored. For example, local system administrators can be allowed to update data in only one subdomain, where global system administrators can update data throughout the enterprise.

The security model is based on public key technology. Each principal, user, or computer, presents credentials in order to gain access to name service data. A network password is established for each NIS+ client, and the client uses it to log in to the naming service. This prevents someone with local root access from becoming an NIS+ client.

The replication model was improved by propagating incremental database updates instead of entire maps. This technique drastically reduces the amount of time and bandwidth required to keep maps synchronized. Instead of performing nightly updates of an entire database, NIS+ servers propagate changes as they occur.

Common Uses for NIS/NIS+

When NIS and NIS+ were developed, they provided critical services for enterprise environments of the time. NIS and NIS+ offered a centralized method for managing data related to user and group accounts, services, and augmented automated operating system installations.

Maintaining User and Group Data

Perhaps the most important use of NIS/NIS+ is to maintain user account and group membership data used during the authentication and authorization process. Whenever users log in to a system running NIS/NIS+, their profile data and credentials are retrieved along with authorization data in the form of a User Identifier (UID) and Group Identifier (GID). The netgroups database also plays a role in the authorization process by maintaining a list of users who can access particular hosts.

Maintaining System Data for Applications

The services , protocols , and rpc databases are important to enterprises deploying custom or non-standard network services. Without NIS/NIS+, local copies of text files on every client in the enterprise would have to be updated if a new service was deployed.

Applications based on secure RPCs require the storage of public and private keys. For security reasons and ease of access, NIS/NIS+ data is heavily used in enterprises deploying these types of applications.

Automating Installations

Another popular use of NIS/NIS+ is to aid in the use of network-based automated installations. Before a system has an operating system installed, it does not have a network identity in the form of an IP address. However, any networked computer has knowledge of its own Media Access Controller (MAC) address. By broadcasting its MAC address, a corresponding IP address is obtained from a server capable of performing this translation. This is accomplished using the Reverse Address Resolution Protocol (RARP). Because this mapping data needs to reside somewhere, and you might have numerous RARP servers in an enterprise, using a common data store makes sense. The NIS/NIS+ ethers database provides this mapping function.

To perform a hands-free installation, the installation server must be able to find information about the client. Specifically, it must know what software configuration to download. This information can be stored in the bootparams database. Because there might be many JumpStart servers that require this information throughout your enterprise, it makes sense to store and retrieve the data using NIS/NIS+. Client identification and bootparams information can also be stored in a DHCP server.

DNS and NIS/NIS+

As wide area network (WAN) bandwidth became cheaper, it became economical to communicate beyond the local area network (LAN). Access to computers throughout the enterprise and between different enterprises became part of normal operations. To facilitate finding systems outside your LAN, the Domain Name System (DNS) was developed as an industry standard and was widely adopted. Because DNS was only designed to assist in locating IP addresses of systems and email servers, it could not provide all the information that NIS could. This led to deployments with a combination of DNS and NIS.

Most enterprises these days deploy the DNS for translation of host names to IP addresses, and for identifying email servers. Some of this information is the same information that is stored in the NIS/NIS+ hosts database. Although you could replace the NIS/NIS+ hosts database with DNS, it is common practice to deploy both. Some applications, such as the Solaris OE sysidtools command (used by Solaris OE installation programs), communicate directly with NIS/NIS+, and therefore require the NIS/NIS+ hosts database. Administrators of some environments, such as computer labs, might find it more convenient to place their host names in the hosts database rather than DNS, because systems outside the lab do not need to access them.

DHCP

Dynamic Host Configuration Protocol (DHCP) servers, while technically not a naming service, do make use of naming services and potentially replace RARP as a mechanism for dynamically assigning or providing host information. DHCP has the advantage of working across subnets by setting up DHCP relay hosts. However, because of its simplicity, RARP remains a popular protocol used by Sun servers.

NIS Limitations

With the progression of technology, legacy naming services such as NIS and NIS+ are left with limitations, mainly due to the their architectural design which evolved under technological demands that are different than today. This section describes some of these limitations.

Architectural Limitations

An operating environment depends on naming service information being readily accessible, so it is critical that the naming service be highly available. To achieve availability, data must be replicated on multiple systems in case one server goes down. NIS replicates data by pushing entire NIS maps from master to slave servers. This means that a change in a single map entry can result in the entire map content being propagated even though the other entries are unchanged. For maps with a small number of entries, this might not be an issue. However, as more and more data is consolidated in single maps, this activity creates a significant amount of network traffic.

Security Issues

NIS clients do not have to authenticate their requests to look at data contained in NIS maps. This means that any system on the network can become an NIS client and have access to naming service dataa critical security concern. A workaround exists which allows you to specify a list of trusted systems and networks, then limit access to only them. However, this feature requires additional administration and it is not hard to spoof an IP address of a trusted system. Also, there is no convenient way to encrypt data sent to NIS clients from the server.

Naming Chaos

NIS domains were originally managed locally, so local administrators frequently created their own domain name scheme and way of naming users. The NIS domain name typically reflected the name or initials of an organization or a geographic location. With the advent of the Internet and the DNS global namespace, enterprises began to register their unique domain names. Depending on the size of your enterprise, you could subdivide the registered DNS domain name, typically along geographical lines. For example, a company like Sun Microsystems, Inc. would have a top-level DNS domain called sun.com and subdomains called east.sun.com , uk.sun.com , and so forth. NIS domain names began to be patterned after DNS domain names, but because of architectural limitations on the size of NIS maps, a further subdivision often became necessary.

NIS map entries need only be unique within an NIS domain, so there was no need to create a global user ID or login name. Likewise, group names only had to be unique within the domain. This led to the practice of allowing users to choose their own login names, or simplistic schemes like first name, first letter of last name. Because the allocation of user names was so casual, the likelihood of name collisions between different NIS domains was high.

Limitation Workarounds

To get around some of the limitations of NIS, some enterprises choose to generate dbm files from authoritative data sources other than NIS source files. For example data is stored and updated in a relational database management system (RDBMS) like Sybase or Oracle, then pushed out nightly to NIS servers. All updates are made on the RDBMS, that in turn updates the NIS master servers. This way the NIS servers are always kept in synchronization.

While this is one method of consolidation, it does have some drawbacks. Custom programs need to be created to generate the dbm files that NIS uses. There is also a lengthy propagation delay.