Using NIS in conjunction with shadow password files is somewhat problematic.
First we have some bad news: using NIS defeats the goals of shadow passwords.
The shadow password scheme was designed to prevent
nonroot users from having access to the encrypted form of the login
passwords. Using NIS to share shadow data by necessity
makes the encrypted passwords available to any user who can listen to the NIS
server replies on the network. A policy to enforce users to choose
“good” passwords is arguably better than trying to shadow
passwords in an NIS environment. Let's take a quick look at how you do it,
should you decide to forge on ahead.
In libc5 there is no real solution to sharing shadow data
using NIS. The only way to distribute password and user information by NIS is
through the standard passwd.* maps. If you do have
shadow passwords installed, the easiest way to share them is to generate a
proper passwd file from /etc/shadow
using tools like pwuncov, and create the NIS maps from
Of course, there are some hacks necessary to use NIS and shadow passwords at
the same time, for instance, by installing an /etc/shadow
file on each host in the network, while distributing user information, through
NIS. However, this hack is really crude and defies the goal of NIS,
which is to ease system administration.
The NIS support in the GNU libc library (libc6) provides support for shadow
password databases. It does not provide any real solution to making your
passwords accessible, but it does simplify password management in
environments in which you do want to use NIS with shadow passwords.
To use it, you must create a shadow.byname database
and add the following line to your /etc/nsswitch.conf :
# Shadow password support
If you use shadow passwords along with NIS, you must try to maintain some
security by restricting access to your NIS database. See Section 13.5” earlier in this chapter.