Solaris Naming Administration Guide

Chapter 3 Introduction to NIS+

This chapter provides an overview of the Network Information Service Plus (NIS+):

Directions for setting up NIS+ and DNS namespaces are contained in Solaris Naming Setup and Configuration Guide. See Glossary for definitions of terms and acronyms you don't recognize.

About NIS+

NIS+ is a network name service similar to NIS but with more features. NIS+ is not an extension of NIS. It is a new software program.

The NIS+ name service is designed to conform to the shape of the organization that installs it, wrapping itself around the bulges and corners of almost any network configuration.

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

The NIS+ namespace is hierarchical, and is similar in structure to the UNIX directory file system. The hierarchical structure allows an NIS+ namespace to be configured to conform to the logical hierarchy of an organization. The namespace's layout of information is unrelated to its physical arrangement. Thus, an NIS+ namespace can be divided into multiple domains that can be administered autonomously. Clients may have access to information in other domains in addition to their own if they have the appropriate permissions.

NIS+ uses a client-server model to store and have access to the information contained in an NIS+ namespace. Each domain is supported by a set of servers. The principal server is called the master server and the backup servers are called replicas. The network information is stored in 16 standard NIS+ tables in an internal NIS+ database. Both master and replica servers run NIS+ server software and both maintain copies of NIS+ tables. Changes made to the NIS+ data on the master server are incrementally propagated automatically to the replicas.

NIS+ includes a sophisticated security system to protect the structure of the namespace and its information. It uses authentication and authorization to verify whether a client's request for information should be fulfilled. Authentication determines whether the information requester is a valid user on the network. Authorization determines whether a particular user is allowed to have or modify the information requested.

Solaris clients use the name service switch (/etc/nsswitch.conf file) to determine from where a workstation will retrieve network information. Such information may be stored in local /etc files, NIS, DNS, or NIS+. You can specify different sources for different types of information in the name service switch.

What NIS+ Can Do for You

NIS+ has some major advantages over NIS:

Secure data access
Hierarchical and decentralized network administration
Very large namespace administration
Access to resources across domains
Incremental updates

With the security system described in "NIS+ Security", you can control a particular user's access to an individual entry in a particular table. This approach to security helps to keep the system secure and administration tasks to be more broadly distributed without risking damage to the entire NIS+ namespace or even to an entire table.

The NIS+ hierarchical structure allows for multiple domains in one namespace. Division into domains makes administration easier to manage. Individual domains can be administered completely independently, thereby relieving the burden on system administrators who would otherwise each be responsible for very large namespaces. As mentioned above, the security system in combination with decentralized network administration allows for a sharing of administrative work load.

Even though domains may be administered independently, all clients can be granted permission to access information across all domains in a namespace. Since a client can only see the tables in its own domain, the client can only have access to tables in other domains by explicitly addressing them.

Incremental updates mean faster updates of information in the namespace. Since domains are administered independently, changes to master server tables only have to be propagated to that master's replicas and not to the entire namespace. Once propagated, these updates are visible to the entire namespace immediately.

How NIS+ Differs From NIS

The Network Information Service Plus (NIS+) differs from the Network Information Service (NIS) in several ways. NIS+ has many new features, and the terminology it uses for concepts similar to NIS is different. Look in the Glossary if you see a term you don't recognize. Table 3-1 gives an overview of the major differences between NIS and NIS+.

Table 3-1 Differences Between NIS and NIS+


NIS	NIS+
Flat domains--no hierarchy	Hierarchical layout--data stored in different levels in the namespace
Data stored in two column maps	Data stored in multi-column tables
Uses no authentication	Uses DES authentication
Single choice of network information source	Name service switch--lets client choose information source: NIS, NIS+, DNS, or local `/etc` files
Updates delayed for batch propagation	Incremental updates propagated immediately

NIS+ was designed to replace NIS. NIS addresses the administration requirements of client-server computing networks prevalent in the 1980s. At that time client-server networks did not usually have more than a few hundred clients and a few multipurpose servers. They were spread across only a few remote sites, and since users were sophisticated and trusted, they did not require security.

However, client-server networks have grown tremendously since the mid-1980s. They now range from 100-10,000 multi-vendor clients supported by 10-100 specialized servers located in sites throughout the world, and they are connected to several "untrusted" public networks. In addition, the information client-server networks store changes much more rapidly than it did during the time of NIS. The size and complexity of these networks required new, autonomous administration practices. NIS+ was designed to address these requirements.

The NIS namespace, being flat, centralizes administration. Because networks in the 1990s require scalability and decentralized administration, the NIS+ namespace was designed with hierarchical domains, like those of DNS.

For example, Figure 3-1, shows a sample company with a parent domain named doc, and two subdomains named sales and manf.

Figure 3-1 Example of Hierarchical Domains

This design enables NIS+ to be used in a range of networks, from small to very large. It also allows the NIS+ service to adapt to the growth of an organization. For example, if a corporation splits itself into two divisions, its NIS+ namespace could be divided into two domains that could be administered autonomously. Just as the Internet delegates administration of domains downward, NIS+ domains can be administered more or less independently of each other.

Although NIS+ uses a domain hierarchy similar to that of DNS, an NIS+ domain is much more than a DNS domain. A DNS domain only stores name and address information about its clients. An NIS+ domain, on the other hand, is a collection of information about the workstations, users, and network services in a portion of an organization.

Although this division into domains makes administration more autonomous and growth easier to manage, it does not make information harder to access. Clients have the same access to information in other domains as they would have had under one umbrella domain. A domain can even be administered from within another domain.

The principal NIS+ server is called the master server, and the backup servers are called replicas. Both master and replica servers run NIS+ server software and both maintain copies of NIS+ tables. Tables store information in NIS+ the way maps store information in NIS. The principal server stores the original tables, and the backup servers store copies.

However, NIS+ uses an updating model that is completely different from the one used by NIS. Since at the time NIS was developed, the type of information it would store changed infrequently, NIS was developed with an update model that focused on stability. Its updates are handled manually and, in large organizations, can take more than a day to propagate to all the replicas. Part of the reason for this is the need to remake and propagate an entire map every time any information in the map changes.

NIS+, however, accepts incremental updates. Changes must still be made on the master server, but once made they are automatically propagated to the replica servers and immediately made available to the entire namespace. You don't have to "make" any maps or wait for propagation.

Details about NIS+ domain structure, servers, and clients, are provided in Chapter 4, The NIS+ Namespace.

An NIS+ domain can be connected to the Internet through its NIS+ clients, using the name service switch (see "NIS+ and the Name Service Switch"). The client, if it is also a DNS client, can set up its switch configuration file to search for information in either DNS zone files or NIS maps--in addition to NIS+ tables.

NIS+ stores information in tables instead of maps or zone files. NIS+ provides 16 types of predefined, or system, tables:

Each table stores a different type of information. For instance, the hosts table stores information about workstation addresses, while the passwd table stores information about users of the network.

NIS+ tables provide two major improvements over the maps used by NIS. First, you can search an NIS+ table by any column, not just the first column (sometimes referred to as the "key"). This eliminates the need for duplicate maps, such as the hosts.byname and hosts.byaddr maps used by NIS. Second, you can access and manipulate the information in NIS+ tables at three levels of granularity: the table level, the entry level, and the column level. NIS+ tables--and the information stored in them--are described in Chapter 5, NIS+ Tables and Information.

You can use NIS in conjunction with NIS+ under the following principles and conditions:

Servers within a domain. While you can have both NIS and NIS+ servers operating in the same domain, doing so is not recommended for long periods. As a general rule, using both services in the same domain should be limited to a relatively short transition period from NIS to NIS+.
Subdomains. If the master server of your root domain is running NIS+, you can set up subdomains whose servers are all running NIS. (If your root domain master server is running NIS, you cannot have subdomains.)
Workstations within a domain.
- If a domain's servers are running NIS+, individual workstations within that domain can be set up to use either NIS+, NIS, or /etc files for their name service information. In order for an NIS+ server to supply the needs of an NIS client, the NIS+ server must be running in NIS-Compatibility mode.
- If a domain's servers are running NIS, individual workstations within that domain can be set up to use either NIS or /etc files for name services (they cannot use NIS+).
The service a workstation uses for various name services is controlled by the workstation's nsswitch.conf file. This file is called the switch file. See Chapter 2, The Name Service Switch for further information.

NIS+ Security

NIS+ protects the structure of the namespace, and the information it stores, by the complementary processes of authorization and authentication.

Authorization. Every component in the namespace specifies the type of operation it will accept and from whom. This is authorization.
Authentication. NIS+ attempts to authenticate every request for access to the namespace. Requests come from NIS+ principals. An NIS+ principal can be a process, machine, root, or a user. Valid NIS+ principals possess an NIS+ credential. NIS+ authenticates the originator of the request (principal) by checking the principal's credential.

If the principal possesses an authentic (valid) credential, and if the principal's request is one that the principal is authorized to perform, NIS+ carries out the request. If either the credential is missing or invalid, or the request is not one the principal is authorized to perform, NIS+ denies the request for access. An introductory description of the entire NIS+ security system is provided in Chapter 6, Security Overview.

NIS+ and the Name Service Switch

NIS+ works in conjunction with a separate program called the name service switch. The name service switch, sometimes referred to as "the switch," enables Solaris operating environmentbased workstations to obtain their information from more than one name service; specifically, from local or /etc files, NIS maps, DNS zone files, or NIS+ tables. The switch not only offers a choice of sources, but allows a workstation to specify different sources for different types of information. A complete description of the switch software and its associated files is provided in Chapter 2, The Name Service Switch.

Solaris 1.x Releases and NIS-Compatibility Mode

NIS+ can be used by workstations running NIS with Solaris 1x or 2x Release software. In other words, machines within an NIS+ domain can have their nsswitch.conf files set to nis rather than nisplus. To access NIS+ service on machines running NIS, you must run the NIS+ servers in NIS-compatibility mode.

NIS-compatibility mode enables an NIS+ server running Solaris operating environment to answer requests from NIS clients while continuing to answer requests from NIS+ clients. NIS+ does this by providing two service interfaces. One responds to NIS+ client requests, while the other responds to NIS client requests.

This mode does not require any additional setup or changes to NIS clients. In fact, NIS clients are not even aware that the server that is responding isn't an NIS server--except that an NIS+ server running in NIS-compatibility mode does not support the ypupdate and ypxfr protocols and thus it cannot be used as a replica or master NIS server. For more information on NIS-compatibility mode, see NIS+ Transition Guide.

Two more differences need to be pointed out. First, instructions for setting up a server in NIS-compatibility mode are slightly different than those used to set up a standard NIS+ server. For details, see Solaris Naming Setup and Configuration Guide. Second, NIS-compatibility mode has security implications for tables in the NIS+ namespace. Since the NIS client software does not have the capability to provide the credentials that NIS+ servers expect from NIS+ clients, all their requests end up classified as unauthenticated. Therefore, to allow NIS clients to access information in NIS+ tables, those tables must provide access rights to unauthenticated requests. This is handled automatically by the utilities used to set up a server in NIS-compatibility mode, as described in Part 2. However, to understand more about the authentication process and NIS-compatibility mode, see Chapter 6, Security Overview.

NIS+ Administration Commands

NIS+ provides a full set of commands for administering a namespace. Table 3-2, below, summarizes them.

Table 3-2 NIS+ Namespace Administration Commands


Command	Description
`nisaddcred`	Creates credentials for NIS+ principals and stores them in the cred table.
`nisaddent`	Adds information from `/etc` files or NIS maps into NIS+ tables.
`nisauthconf`	Optionally configure Diffie-Hellman key length.
`nisbackup`	Backs up NIS directories.
`nis_cachemgr`	Starts the NIS+ cache manager on an NIS+ client.
`niscat`	Displays the contents of NIS+ tables.
`nis_checkpoint`	Forces service to checkpoint data that has been entered in the log but not checkpointed to disk.
`nischgrp`	Changes the group owner of an NIS+ object.
`nischmod`	Changes an object's access rights.
`nischown`	Changes the owner of an NIS+ object.
`nischttl`	Changes an NIS+ object's time-to-live value.
`nisclient`	Initializes NIS+ principals.
`nisdefaults`	Lists an NIS+ object's default values: domain name, group name, workstation name, NIS+ principal name, access rights, directory search path, and time-to-live
`nisgrep`	Searches for entries in an NIS+ table.
`nisgrpadm`	Creates or destroys an NIS+ group, or displays a list of its members. Also adds members to a group, removes them, or tests them for membership in the group.
`nisinit`	Initializes an NIS+ client or server.
`nisln`	Creates a symbolic link between two NIS+ tables.
`nislog`	Displays the contents of NIS+ transaction log.
`nisls`	Lists the contents of an NIS+ directory.
`nismatch`	Searches for entries in an NIS+ table.
`nismkdir`	Creates an NIS+ directory and specifies its master and replica servers.
`nispasswd`	Changes password information stored in the NIS+ passwd table. (Rather than using `nispasswd`, you should use `passwd` or `passwd -r nisplus`.)
`nis_ping`	Forces a replica to update its data from the master server.
`nispopulate`	Populates the NIS+ tables in a new NIS+ domain.
`nisprefadm`	Specifies the order in which clients are to seek NIS+ information from NIS+ servers.
`nisrestore`	Restores previously backed up NIS+ directories and can also be used to quickly bring online new NIS+ replica servers.
`nisrm`	Removes NIS+ objects (except directories) from the namespace.
`nisrmdir`	Removes NIS+ directories and replicas from the namespace.
`nisserver`	Shell script used to set up a new NIS+ server.
`nissetup`	Creates `org_dir` and `groups_dir` directories and a complete set of (unpopulated) NIS+ tables for an NIS+ domain.
`nisshowcache`	Lists the contents of the NIS+ shared cache maintained by the NIS+ cache manager.
`nisstat`	Reports statistics and other information about an NIS+ server.
`nistbladm`	Creates or deletes NIS+ tables, and adds, modifies or deletes entries in an NIS+ table.
`nistest`	Reports the current state of the NIS+ namespace.
`nisupdkeys`	Updates the public keys stored in an NIS+ object.
`passwd`	Changes password information stored in the NIS+ Passwd table. Also administers password aging and other password-related parameters.

NIS+ API

The NIS+ application programmer's interface (API) is a group of functions that can be called by an application to access and modify NIS+ objects. The NIS+ API has 54 functions that fall into nine categories:

Object manipulation functions (nis_names())
Table access functions (nis_tables())
Local name functions (nis_local_names())
Group manipulation functions (nis_groups())
Application subroutine functions (nis_subr())
Miscellaneous functions (nis_misc())
Database access functions (nis_db())
Error message display functions (nis_error())
Transaction log functions (nis_admin())