NIS+

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

NIS addresses the administrative requirements of small-to-medium client/server computing networksthose 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 but not least, systems today require a higher level of security than provided by NIS, 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+ 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 in to 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 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 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 12.8.

Table 12.8. 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. 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 reasonsthe principal making the request might not be logged in on that system, the clocks might be out of sync, there might be a key mismatch, and so forth.)