NIS+
The NIS+ is similar to NIS but with more features. NIS+ is not an extension of NIS but a new software program. NIS+ was designed to replace NIS.
NIS addresses the administrative requirements of small-to-moderate client server computing networks—those with less than a few hundred clients. NIS+ is designed for the larger networks now prevalent in which systems are spread across remote sites in various time zones and in which clients number into the thousands. In addition, the information stored in networks today changes much more frequently, and NIS had to be updated to handle this environment. Lastly, systems today require a high level of security, and NIS+ addresses many security issues that NIS did not.
NIS+ is not an objective covered in depth in the System Administration Certification exam Part II. You are asked a few general overview questions regarding NIS+ that are covered in this text, but a working knowledge of NIS+ is not required until you take the Sun Certified Network Administrator examination.
Hierarchical Namespace
NIS+ enables you to store information about workstation addresses, security information, mail information, Ethernet interfaces, and network services in central locations in which 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 the needs of an organization. NIS+ can be arranged to manage large networks with more than one domain. Although the arrangement of a NIS+ namespace can vary from site to site, all sites use the same structural components: directories, tables, and groups. The 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 a NIS+ environment, most namespace information is stored in NIS+ tables; think of them as being similar to NIS maps, which were described earlier. Without a name service, most network information would be stored in /etc files and almost all NIS+ tables have corresponding /etc files. With the NIS service, network information is stored in NIS maps that also mostly correspond with /etc files. All NIS+ tables are stored in the domain's org_dir NIS+ directory object except the admin and groups tables that are stored in the groups_dir directory object. The tables that come default as part of the standard distribution of NIS+ are described in Table 7-4. Users and application developers frequently create NIS+ compatible tables for their own purposes.
Table 7-4 Standard NIS+ Tables
|
NIS+ Table |
Description |
|
auto_home |
This table is an indirect automounter map that enables a 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 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 client users who are enabled to 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. This table 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, but do not have to be, NIS+ principals. 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 together before it propagates them to its replicas (slaves).
NIS+ Security
NIS+ security is enhanced in two ways: First, it has the capability to authenticate access to the service, and thus, to discriminate between access that is enabled to members of the community and other network entities. Second, it includes an authorization model that enables specific rights to be granted or denied based on this authentication.
Authentication
Authentication is used to identify NIS+ principals. A 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 a NIS+ client system. Thus, a NIS+ principal can be a client user or a client workstation. Every time a principal (user or system) tries to access a NIS+ object, the user's identity and secure RPC password is 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, which are summarized as:
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 a NIS+ object. Access rights are similar to file permissions. There are four types of access rights:
Read Principal can read the contents of the object
Modify Principal can modify the contents of the object
Create Principal can create new objects in a table or directory
Destroy Principal can destroy objects in a table or directory
Access rights are displayed as 16 characters, and they can be displayed with the command nisls –l and changed with the command nischmod.
The NIS+ security system enables NIS+ administrators to specify different read, modify, create, or destroy rights to NIS+ objects for each class. Thus, 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 enabled 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. A NIS+ server can operate at one of three security levels, which are summarized in Table 7-5.
Table 7-5 NIS+ Security Levels
|
Security Level |
Description |
|
0 |
Security level 0 is designed for testing and setting up the initial NIS+ namespace. A 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 it should only be used by administrators for that purpose. Level 0 should not be used on networks in normal operation by regular users. |
|
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 the default level assigned to a NIS server. It authenticates only requests that use Data Encryption Standard (DES) credentials (see DES 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, such as the principal making the request is not keylogged in on that system, the clocks are out of sync, there is a key mismatch, and so forth.) |