14.2 Sun's NIS+

NIS was designed for a small, friendly computing environment. As Sun Microsystems' customers began to build networks with thousands or tens of thousands of workstations, NIS started to show its weaknesses:

• NIS maps could be updated only by logging onto the server and editing files.

• NIS servers could be updated only in a single batch operation. Updates could take many minutes, or even hours, to complete.

• All information transmitted by NIS was transmitted without encryption, making it subject to eavesdropping.

• NIS updates themselves were authenticated with AUTH_UNIX RPC authentication, making them subject to spoofing.

To respond to these complaints, Sun started working on an NIS replacement in 1990. That system was released a few years later as NIS+.

NIS+ quickly earned a bad reputation. By all accounts, the early releases were virtually untested and rarely operated as promised. Furthermore, the documentation was confusing and incomplete. Sun sent engineers into the field to debug their software at customer sites. Eventually, Sun worked the bugs out of NIS+, and today it is a more reliable system for secure network management and control.

An excellent reference for people using NIS+ is Rick Ramsey's book, All About Administrating NIS+ (SunSoft Press, Prentice Hall, 1994).

14.2.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+ principal 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; see Section 13.2.1.)

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.

14.2.2 NIS+ Tables and Other Objects

All information stored on an NIS+ server is stored in the form of objects. NIS+ supports three fundamental types of objects:^[7]

^[7] Other types of objects are supported, but they aren't really important to this discussion. Interested readers should consult the manpages.

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.

Directory objects

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

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

14.2.3 Using NIS+

Using an NIS+ domain can be remarkably pleasant. When a user logs into 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 which kind of access to the object.

NIS+ allows four types of access to objects:

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

The way that NIS+ commands display access rights is 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 4 characters represent the rights for "nobody", rather than "owner", as shown in Figure 14-2.

Figure 14-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 have the additional ability of modifying 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.

passwd:   files nisplus nis
shadow:   files nisplus nis
group:    files nisplus nis
hosts:    files nisplus nis dns
services: nisplus [NOTFOUND=return] files

14.2.3.1 Changing your password

Once a user has her NIS+ account set up, she should use the nispasswd command to change the password:

% nispasswd
Changing password for simsong on NIS+ server.
Old login password: fj39=3-f

New login password: fj43fadf

Re-enter new  password:fj43fadf

        NIS+ password information changed for simsong
        NIS+ credential information changed for simsong
%

14.2.3.2 When a user's passwords don't match

If a user has a different password stored on his workstation and on the Secure RPC server, he will see the following message when he logs in:

login: simsong
Password: fj39=3-f

Password does not decrypt secret key for unix.237@cpg.com.
Last login: Sun Nov 19 18:03:42 from sun.vineyard.net
Sun Microsystems Inc.   SunOS 5.4       Generic July 1994
%

In this case, the user has a problem because the password that the user knows and uses to log in does not, for some reason, match the password that was used to encrypt the password on the Secure RPC server. The user can't change his password with the nispasswd program because he doesn't know his NIS password:

% nispasswd
Changing password for simsong on NIS+ server.
Old login password:fj39=4-f

Sorry.
%

Likewise, the superuser can't run the nispasswd program for the user. The only solution is for the system administrator to become the superuser and give the user a new key:

# newkey -u simsong
Updating nisplus publickey database.
Adding new key for unix.237@cpg.com.
Enter simsong's login password: fj39=3-f

#

This procedure sets the user's Secure RPC password to be the same as his login password. Note that you must know the user's login password. If you don't, you'll get this error:

# newkey -u simsong
Updating nisplus publickey database.
Adding new key for unix.237@cpg.com.
Enter simsong's login password: nosmis

newkey: ERROR, password differs from login password.
#

After the user has a new key, he can then use the nispasswd command to change his password, as shown above.

14.2.4 NIS+ Limitations

If properly configured, NIS+ can be a very secure system for network management and authentication. However, as with 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 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 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

These levels are described in Table 14-2. Make sure that your server is operating at level 2, which is the default level.