One of the major applications of NIS is in synchronizing user and account information on all hosts in a NIS domain. To this end, you usually keep only a small local /etc/passwd file, to which the site-wide information from the NIS maps is appended. However, simply enabling NIS lookups for this service in nsswitch.conf is not nearly enough.
When relying on the password information distributed by NIS, you first have to make sure that the numeric user id's of any users you have in your local passwd file match the NIS server's idea of user id's. You will want this for other purposes as well, like mounting NFS volumes from other hosts in your network.
If any of the numeric ids in /etc/passwd or /etc/group deviate from those in the maps, you have to adjust file ownerships for all files that belong to that user. First you should change all uids and gids in passwd and group to the new values; then find all files that belong to the users just changed, and finally change their ownership. Assume news used to have a user id of 9, and okir had a user id of 103, which were changed to some other value; you could then issue the following commands:
It is important that you execute these commands with the new passwd file installed, and that you collect all file names before you change the ownership of any of them. To update the group ownerships of files, you will use a similar command.
Having done this, the numerical uid's and gid's on your system will agree with those on all other hosts in your NIS domain. The next step will be to add configuration lines to nsswitch.conf that enables NIS lookups for user and group information:
This makes the login command and all its friends first query the NIS maps when a user tries to log in, and if this lookup fails, fall back to the local files. Usually, you will remove almost all users from your local files, and only leave entries for root and generic accounts like mail in it. This is because some vital system tasks may require to map uids to user names or vice versa. For example, administrative cron jobs may execute the su command to temporarily become news, or the UUCP subsystem may mail a status report. If news and uucp don't have entries in the local passwd file, these jobs will fail miserably during a NIS brownout.
There are two big caveats in order here: on one hand, the setup as described up to here only works for login suites that don't use shadow password, like those included in the util-linux package. The intricacies of using shadow passwords with NIS will be covered below. On the other hand, the login commands are not the only ones that access the passwd file-- look at the ls command which most people use almost constantly. Whenever doing a long listing, ls will display the symbolic names for user and group owners of a file; that is, for each uid and gid it encounters, it will have to query the NIS server once. This will slow things down rather badly if your local network is clogged, or, even worse, when the NIS server is not on the same physical network, so that datagrams have to pass through a router.
Still, this is not the whole story yet. Imagine what happens if a user wants to change her password. Usually, she will invoke passwd, which reads the new password and updates the local passwd file. This is impossible with NIS, since that file isn't available locally anymore, but having users log into the NIS server whenever they want to change their password is not an option either. Therefore, NIS provides a drop-in replacement for passwd called yppasswd, which does the analogous thing in the presence of NIS. To change the password on the server host, it contacts the yppasswdd daemon on that host via RPC, and provides it with the updated password information. Usually, you install yppasswd over the normal program by doing something like this:
At the same time you have to install rpc.yppasswdd on the server and start it from rc.inet2. This will effectively hide any of the contortions of NIS from your users.