End of Life for NIS+ It is important to note that Sun Microsystems issued an end of support notice for NIS+ with the release of Solaris 9, and again with the release of Solaris 10. It is likely that Solaris 10 will be the last release to contain NIS+ as a naming service. Sun recommends that users of NIS+ migrate to LDAPusing the Sun Java System Directory Server. To this end, and because NIS+ is not mentioned as an objective for this exam, it is only briefly covered in this chapter.
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.
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 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 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.
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:
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.