About NIS

So what is NIS?

Network Information Service (NIS), developed by Sun Microsystems, provides centralized distribution of account information such as user names, passwords, and group membership to UNIX systems in order to control who can access those systems. Originally called "Yellow Pages" (YP), NIS has been around since 1985 and is broadly adopted and deeply embedded into many organizations' infrastructure. It is also used to manage devices such as network-attached storage (NAS) and UNIX-based applications.

Sun tried to address some of NIS' limitations with NIS+, but it was never widely adopted, and NIS+ has been subsequently "end-of-lifed" by Sun. At the same time, Sun is telling customers to get off of NIS and move to LDAP. According to the Gartner Group "more Gartner clients are moving away from NIS because of poor support and weak security for data in transit on networks" (Gartner report ID Number: G00149425).

NIS Architecture

NIS provides centralized storage and distribution of information that needs to be known throughout the network. The information accessed is stored in files called maps. NIS has a master-slave architecture: data can be updated only at a central, master server, where all maps are maintained. Slaves can handle client requests for map access, but the slaves can make no changes to the maps. Changes are made only at the master server, and then distributed through the master NIS server to the slaves.

NIS is implemented through several daemons that handle NIS requests: ypserv on the server side, and ypbind on the client side. Updated maps can be transferred to NIS slaves either manually (using yppush) or automatically through ypxfrd (NIS slaves check timestamps on the master and update their maps as needed).

In a typical NIS environment, the NIS server is used to centrally manage a set of database maps that correspond to the system configuration files that are commonly found on Unix systems — such as the /etc/passwd, /etc/group, and secret authentication hashes in /etc/shadow, /etc/hosts, and /etc/services files — for a set of computers that make up a NIS domain.

Besides corresponding to a specific configuration file, each NIS map consists of a set of keys and values, and a version number for the data. When computers on the network require information stored in NIS maps, they send a NIS client request to query for the information. Each client computer that needs access to the information in the NIS database maps runs the ypbind process to identify and connect to the NIS server best suited to respond to its request. When the NIS server receives a request, it replies with the appropriate information from its set of NIS maps.

Defining netgroups allows an enterprise to restrict access to hosts, NFS access and administrators by checking permissions when processing requests for remote mounts, remote logins, and remote shells in a NIS domain. The main database for netgroups is stored on the NIS master server in the /etc/netgroup file. For remote mounts, the information in netgroup is used to classify machines; for remote logins and remote shells, it is used to classify users. NIS clients can use netgroups to include the map entries for the members of a netgroup in the password file, /etc/passwd.

The automount map, called auto.master, is typically used to share home directories on a NFS file share. The automount daemon reads the auto.master map to find out which directory to mount either at login or when a file is touched in the directory. A script can be used instead to mount a directory instead of "what should be mapped".

Additional definitions and background information on NIS

Wikipedia write-up of NIS
Linux.com intro to NIS
Centrify chalktalk on what is NIS and NIS Migration
IBM's overview of NIS