19.5.1 What NIS+ Does

NIS + creates network databases that are used to store information about computers and users within an organization. NIS + calls these databases tables ; they are functionally similar to NIS maps . Unlike NIS , NIS + allows for incremental updates of the information stored on replicated database servers throughout the network.

Each NIS + domain has one and only one NIS + root domain server . This is a computer that contains the master copy of the information stored in the NIS + root domain . The information stored on this server can be replicated, allowing the network to remain usable even when the root server is down or unavailable. There may also be NIS + servers for subdomains.

Entities that communicate using NIS + are called NIS+ principals . An NIS + principle may be a host or an authenticated user. Each NIS + principal has a public key and a secret key, which are stored on an NIS + server in the domain. (As this is Secure RPC , the secret key is stored encrypted.)

All communication between NIS + servers and NIS + principals take place through Secure RPC . This makes the communication resistant to both eavesdropping and spoofing attacks. NIS + also oversees the creation and management of Secure RPC keys; by virtue of using NIS +, every member of the organization is enabled to use Secure RPC .

19.5.2 NIS+ Objects

All information stored on an NIS + server is stored in the form of objects. NIS + supports three fundamental kinds of objects:

Table objects

Store configuration information.

Group objects

Used for NIS + authorization, NIS + groups give you a way to collectively refer to a set of NIS + principals (users or machines) at a single time.

Directories

Provide structure to an NIS + server. Directories can store tables, groups, or other directories, creating a tree structure on the NIS + server similar to the UNIX filesystem.

19.5.3 NIS+ Tables

Information stored in NIS + tables can be retrieved using any table column as a key; NIS + thus eliminates the need under NIS to have multiple NIS maps (such as group.bygid and group.byname) . NIS + predefines 16 tables (see Table 19.2 ); users are free to create additional tables of their own.

Table 19.2: NIS+ Predefined Tables

Table	Equivalent UNIX File	Stores
Hosts	/etc/hosts	IP address and hostname of every workstation in the NIS+ domain.
Bootparams	/etc/bootparams	Configuration information for diskless clients, including location of root, swap and dump partitions.
Passwd	/etc/passwd	User account information (password, full name, home directory, etc.)
Cred		Secure RPC credentials for users in the domain.
Group	/etc/group	Groupnames, passwords, and members of every UNIX group.
Netgroup	/etc/netgroup	Netgroups to which workstations and users belong.
Mail_Aliases	/usr/lib/aliases /etc/aliases /etc/mail/aliases	Electronic mail aliases.
Timezone	/etc/timezone	The time zone of each workstation in the domain.
Networks	/etc/networks	The networks in the domain and their canonical names.
Netmasks	/etc/inet/netmasks /etc/netmasks	The name of each network in the domain and its associated netmask.
Ethers	/etc/ethers	The Ethernet address of every workstation in the domain.
Services	/etc/services	The port number for every Internet service used in the domain.
Protocols	/etc/protocols	The IP protocols used in the domain.
RPC		The RPC program numbers for RPC servers in the domain.
Outcome	None	The location of home directories for users in the domain.
Auto_Mounter	None	Information for Sun's Automounter.

19.5.4 Using NIS+

For users, using an NIS + domain can be remarkably pleasant. When a user logs in to a workstation, the /bin/login command automatically acquires the user's NIS + security credentials and attempts to decrypt them with the user's login password.

If the account password and the NIS + credentials password are the same (and they usually are), the NIS + keyserv process will cache the user's secret key and the user will have transparent access to all Secure RPC services. If the account password and the NIS + credentials password are not the same, then the user will need to manually log in to the NIS + domain by using the keylogin command.

NIS + users should change their passwords with the NIS + nispasswd command, which works in much the same way as the standard UNIX passwd command.

NIS + security is implemented by providing a means for authenticating users, and by establishing access control lists that control the ways that those authenticated users can interact with the information stored in NIS + tables. NIS + provides for two authentication types:

LOCAL

Authentication based on the UID of the UNIX process executing the NIS + command. LOCAL authentication is used largely for administrating the root NIS + server.

DES

Authentication based on Secure RPC . Users must have their public key and encrypted secret key stored in the NIS + Cred table to use DES authentication.

Like UNIX files, each NIS + object has an owner , which is usually the object's creator. (An object's owner can be changed with the nischown command.) NIS + objects also have access control lists, which are used to control which principals have what kind of access to the object.

NIS + allows four kinds of access to objects:

Read	Ability to read the contents of the object.
Modify	Ability to modify the contents of the object.
Create	Ability to create new objects within the table.
Destroy	Ability to destroy objects contained within the table.

NIS + maintains a list of these access rights for four different kinds of principals:

Nobody	Unauthenticated requests, such as requests from individuals who do not have NIS+ credentials within this NIS+ domain.
Owner	The principal that created the object (or that was assigned ownership via the nischown command).
Group	Other principals in the object's group.
World	Other principals within the object's NIS+ domain.

The way that NIS + commands display access rights similar to the way that the UNIX ls command displays file permissions. The key difference is that NIS + access rights are displayed as a list of 16 characters, and the first four characters represent the rights for "nobody," rather than "owner," as shown in Figure 19.2 .

Figure 19.2: NIS+ access rights are displayed as a list of 16 characters

NIS + tables may provide additional access privileges for individual rows, columns or entries that they contain. Thus, all authenticated users may have read access to an entire table, but each user may further have the ability to modify the row of the table associated with the user's own account. Note that while individual rows, columns or entries can broaden the access control list, they cannot impose more restrictive rules.

19.5.5 NIS+ Limitations

If properly configured, NIS + can be a very secure system for network management and authentication. However, like all security systems, it is possible to make a mistake in the configuration or management of NIS + that would render a network that it protects somewhat less than absolutely secure.

Here are some things to be aware of:

• Do not run NIS + in NIS compatibility mode . NIS + has an NIS compatibility mode that allows the NIS + server to interoperate with NIS clients. If you run NIS + in this mode, then any NIS server on your network (and possibly other networks as well) will have the ability to access any piece of information stored within your NIS + server. Typically, NIS access is used by attackers to obtain a copy of your domain's encrypted password file, which is then used to probe for weaknesses.

• Manually inspect the permissions of your NIS + objects on a regular basis . System integrity checking software such as COPS and Tripwire does not exist (yet) for NIS +. In its absence, you must manually inspect the NIS + tables, directories and groups on a regular basis. Be on the lookout for objects that can be modified by Nobody or by World; also be on the lookout for tables in which new objects can be created by these principal classes.

• Secure the computers on which your NIS + servers are running . Your NIS + server is only as secure as the computer on which it is running. If attackers can obtain root access on your NIS + server, they can make any change that they wish to your NIS + domain, including creating new users, changing user passwords, and even changing your NIS + server's master password.

• NIS + servers operate at one of three security levels, described in Table 19.3 . Make sure that your server is operating at level 2, which is the default level.

Table 19.3: NIS+ Server Security Levels

Security Level	Description
0	NIS+ server runs with all security options turned off. Any NIS+ principal may make any change to any NIS+ object. This level is designed for testing and initially setting up the NIS+ namespace. Security level 0 should not be present in a shipping product (but for some reason it is.) Do not use security level 0.
1	NIS+ server runs with security turned on, but with DES authentication turned off. That is, the server will respond to any request in which LOCAL or DES authentication is specified, opening it up to a wide variety of attacks. Security level 1 is designed for testing and debugging; like security level 0, it should not be present in a shipping "security" product. Do not use it.
2	NIS+ server runs with full security authentication and access checking enabled. Only run NIS+ servers at security level 2.