NIS+

NIS+ is similar to NIS, but with more features. NIS+ is not an extension of NIS, but a new software program. It was designed to replace NIS.

NIS addresses the administrative requirements of small-to-medium client/server computing networks—those with less than a few hundred clients. Some sites with thousands of users find NIS adequate as well. NIS+ is designed for the now-prevalent larger networks in which systems are spread across remote sites in various time zones and in which clients number in the thousands. In addition, the information stored in networks today changes much more frequently, and NIS had to be updated to handle this environment. Last, systems today require a high level of security, and NIS+ addresses many security issues that NIS did not.

Hierarchical Namespace

NIS+ lets you store information about workstation addresses, security, mail, Ethernet interfaces, and network services in central locations where all workstations on a network can access it. This configuration of network information is referred to as the NIS+ namespace.

The NIS+ namespace is the arrangement of information stored by NIS+. The namespace can be arranged in a variety of ways to fit an organization’s needs. NIS+ can be arranged to manage large networks with more than one domain. Although the arrangement of an NIS+ namespace can vary from site to site, all sites use the same structural components: directories, tables, and groups. These components are called objects, and they can be arranged into a hierarchy that resembles a UNIX file system.

Directory objects form the skeleton of the namespace. When arranged in a treelike structure, they divide the namespace into separate parts, much like UNIX directories and subdirectories. The topmost directory in a namespace is the root directory. If a namespace is flat, it has only one directory: the root directory. The directory objects beneath the root directory are called directories.

A namespace can have several levels of directories. When identifying the relation of one directory to another, the directory beneath is called the child directory, and the directory above is the parent.

Although UNIX directories are designed to hold UNIX files, NIS+ directories are designed to hold NIS+ objects: other directories, tables, and groups. Any NIS+ directory that stores NIS+ groups is named groups_dir, and any directory that stores NIS+ system tables is named org_dir.

NIS+ Tables

In an NIS+ environment, most namespace information is stored in NIS+ tables; think of them as being similar to NIS maps, which were described earlier. All NIS+ tables are stored in the domain’s org_dir NIS+ directory object except the admin and groups tables, which are stored in the groups_dir directory object. The tables that come as default with the standard distribution of NIS+ are described in Table 23.8. Users and application developers frequently create tables that are compatible with NIS+ for their own purposes.

Table 23.8. Standard NIS+ Tables

NIS+ Table	Description
auto_home	This table is an indirect automounter map that allows an NIS+ client to mount the home directory of any user in the domain.
auto_master	This table lists all the automounter maps in a domain. For direct maps, the auto_master table provides a map name. For indirect maps, it provides both a map name and the top directory of its mount point.
bootparams	This table stores configuration information about every diskless workstation in a domain. A diskless workstation is a workstation that is connected to a network but that has no hard disk.
client_info	This optional internal NIS+ table is used to store server preferences for the domain in which it resides.
cred	This table stores credential information about NIS+ principals. Each domain has one cred table, which stores the credential information of client workstations that belong to that domain and the client users who can log into them.
ethers	This table stores information about the 48-bit Ethernet addresses of workstations in the domain.
group	This table stores information about UNIX user groups.
hosts	This table associates the names of all the workstations in a domain with their IP addresses. The workstations are usually NIS+ clients, but they don’t have to be.
mail_aliases	This table lists the domain’s mail aliases recognized by sendmail.
netgroup	This table defines network-wide groups used to check permissions for remote mounts, logins, and shells. The members of net groups used for remote mounts are workstations; for remote logins and shells, the members are users.
netmasks	This table contains the network masks used to implement standard internetwork subnetting.
networks	This table lists the networks of the Internet. It is normally created from the official network table maintained at the Network Information Control Center (NIC), although you might need to add your local networks to it.
passwd	This table contains information about the accounts of users in a domain. These users generally are NIS+ principals, but they don’t have to be. However, remember that if they are NIS+ principals, their credentials are not stored here but in the domain’s cred table. The passwd table usually grants read permission to the world (or to nobody). This table contains all logins except root, which is stored in the local /etc/passwd file.
protocols	This table lists the protocols used by the internetwork.
rpc	This table lists the names of RPC programs.
services	This table stores information about the services available on the internetwork.
timezone	This table lists the default time zone of every workstation in the domain.

NIS+ tables can be manipulated with Admintool. The NIS+ master server updates its objects immediately; however, it tries to batch several updates before it propagates them to its replicas (slaves).

NIS+ Security

NIS+ security is enhanced in two ways. First, it can authenticate access to the service, so it can discriminate between access that is enabled to members of the community and other network entities. Second, it includes an authorization model that allows specific rights to be granted or denied based on this authentication.

Authentication

Authentication is used to identify NIS+ principals. An NIS+ principal might be someone who is logged into a client system as a regular user, someone who is logged in as superuser, or any process that runs with superuser permission on an NIS+ client system. Thus, an NIS+ principal can be a client user or a client workstation. Every time a principal (user or system) tries to access an NIS+ object, the user’s identity and secure RPC password are confirmed and validated.

Authorization

Authorization is used to specify access rights. Every time NIS+ principals try to access NIS+ objects, they are placed in one of four authorization classes, or categories:

• Owner A single NIS+ principal

• Group A collection of NIS+ principals

• World All principals authenticated by NIS+

• Nobody Unauthenticated principals

The NIS+ server finds out what access rights are assigned to that principal by that particular object. If the access rights match, the server answers the request. If they do not match, the server denies the request and returns an error message.

NIS+ authorization is the process of granting NIS+ principals access rights to an NIS+ object. Access rights are similar to file permissions. Four types of access rights exist:

• Read The principal can read the contents of the object.

• Modify The principal can modify the contents of the object.

• Create The principal can create new objects in a table or directory.

• Destroy The principal can destroy objects in a table or directory.

Access rights are displayed as 16 characters. They can be displayed with the command nisls -l and can be changed with the command nischmod.

The NIS+ security system lets NIS+ administrators specify different read, modify, create, and destroy rights to NIS+ objects for each class. For example, a given class could be permitted to modify a particular column in the passwd table but not read that column, or a different class could be allowed to read some entries of a table but not others.

The implementation of the authorization scheme I just described is determined by the domain’s level of security. An NIS+ server can operate at one of three security levels, summarized in Table 23.9.

Table 23.9. NIS+ Security Levels

Security Level	Description
0	Security level 0 is designed for testing and setting up the initial NIS+ namespace. An NIS+ server running at security level 0 grants any NIS+ principal full access rights to all NIS+ objects in the domain. Level 0 is for setup purposes only, and administrators should use it only for that purpose. Regular users should not use level 0 on networks in normal operation.
1	Security level 1 uses AUTH_SYS security. This level is not supported by NIS+, and it should not be used.
2	Security level 2 is the default. It is the highest level of security currently provided by NIS+ and is the default level assigned to an NIS+ server. It authenticates only requests that use Data Encryption Standard (DES) credentials (DES is described in the next section). Requests with no credentials are assigned to the nobody class and have whatever access rights have been granted to that class. Requests that use invalid DES credentials are retried. After repeated failures to obtain a valid DES credential, requests with invalid credentials fail with an authentication error. (A credential might be invalid for a variety of reasons—the principal making the request might not be keylogged in on that system, the clocks might be out of sync, there might be a key mismatch, and so forth.)