Steve's BOFH Basics Guide to NIS

Introduction

NIS (short for Network Information System) is a Sun (spit) system for maintaining a central store of passwords, groups and netgroups. It can also store other objects such as network names, services, mail aliases, protocols etc... but we'll ignore that for now.

One or preferably more (typically 2 to 4 per site) servers store this information and are used by other servers. The sites storing the information are known as NIS servers and sites using the information are known as NIS clients. Some of the information needs to be user changeable - eg. passwords, shells and finger information and changes not to be reflected on all NIS servers. For simple installations such as ours, this is ensured by nominating one server the master server and forcing all changes to occur there. This server is responsible for updating all the other servers when a change occurs.

There are two ways of changing information:

NIS Related Programs

The tools for direct direct editing (which MUST be run as root) are:

ypm-adduser - Simply adds one uses to the passwd and shadow files. Do not use for for most user additions - use /usr/local/sbin/adduser instead.

ypm-chage - expire a password. Note that we currently do not expire password at all as it simply causes user confusion.

ypm-chfn - changes a given user's finger information. Users can use chfn instead to change their own finger information.

ypm-chsh - changes a given user's shell. Users can use chsh instead to change their own shell.

ypm-deluser - removes a user from the password and shadow files. Not tested.

ypm-passwd - changes a user's password. The standard passwd will not allow anyone to change a password without supplying the previous password. This command allows root to change anyone's password.

These changes do not take affect until ypm-update is used. Changes will take affect on all NIS servers within 30 seconds.

As has already been mentioned, users do not see the complexities of NIS. They have the chfn, chsh and passwd to change their own information.

Daemons

The NIS system uses 3 daemons:
ypbind - This provides libc and other programs such as ypcat, ypwhich, passwd, chfn and chsh with details of the servers - both the default standard and the master server. It forks on startup and runs two copies known as master and slave. It should run on all systems that needs to access NIS servers. Recent changes to libc obsolete some of its functions but it is still needed for chsh, chfn, passwd and ypwhich to run correctly. It uses the information in /etc/yp.conf to find its servers.

ypserv - This is the password server which gives out passwords on request. It does not handle password changes. It should be run on at least 2 machines so that if one server goes down, it should fall-back to a second server (fall-back is currently unreliable but should improve in new versions of libc). It stores its databases in /var/nis/fish-fingers. "fish-fingers" is known as the domain name and was an important security feature in early NIS systems and should have been revealed. It failed as a security feature and we do not rely on it being kept secure.

yppasswdd - This takes connections from the passwd, chsh and chfn programs and password, shell or finger information changes. See below for security features.

Files

Important files and directories:

Security

Here is an outline of the security features. If implemented properly, they give an equivalent security level to shadow passwords. If not, security is no better than the old /etc/passwd scheme.

Port security - only processes running as root can obtain ports in the range 2-1023. Programs that may be expected to read shadow passwords (such as all the programs that need to access /etc/shadow via pam in redhat suite) are already run as root by another process (eg. the telnetd or rlogind) or are suid-root. Thus all programs that have a valid requirement for the hashed form of the password run as root. Thus any requests for lines from shadow file that do not originate on a privileged port do not need the hashed form of the password. Password Mungling - If a connection does not originate at a privileged port, the hashed form of the password in the shadow database is replaced by an "x". Restricted access - Connections to the passwords servers are only allowed from hosts in the 10.* domain. Thus outside users running as root cannot obtain password hashes.

Secure passwords changes - We have been careful to ensure that all password requests passing over the net only send hashed versions of passwords. When we change passwords, we have to be sure that the person trying to change their password is who they claim to be and thus they have to send their own password over the net. They, however, only send the hashed version of their new password. This is a minor security feature.

Where the code came from

ypserv and ypbind are standard redhat packages or contrib packages. yppasswdd is very loosely based on existing system but has had the standard shadow suite included with it and contains many local bug fixes. All standard yppasswdd that I examined are broken. If you need to update to a different yppasswdd, check it very carefully against all our changes.

chsh, chfn and password are similar to those distributed with the yppasswdd with minor fixes.

The ypm-* suite of utilities are the standard shadow suite recompiled with /etc/passwd replaced by /var/nis/files/passwd and /etc/shadow by /var/nis/files/shadow. This was already necessary to compile the shadow suite into yppasswdd.

You should never need to know any of this. The adduser script handles the /var/nis/files/* directly and performs all the necessary updates. passwd, chfn and chsh are automated via the passwd, chfn, chsh and ypm-passwd, ypm-chfn and ypm-chsh commands.