Managing NFS and NIS, 2nd Edition - Mike Eisler [28]
/etc/passwd
Usernames and user IDs
/etc/protocols
Network protocol names and numbers
/etc/publickey
Public key database for RPC/dh
/etc/rpc
Remote procedure call program numbers
/etc/services
Network port numbers and service names
/etc/shadow
User passwords
With the exception of netgroup, these are all standard Solaris administrative files. Once NIS is running, it will replace or supplement all of these files, depending on how /etc/nsswitch.conf is configured. /etc/netgroup is an administrative file that is only consulted via the NIS database. Before creating it, see Section 3.3.2 later in this chapter.
Make sure that your /etc/passwd file on the master server does not include the entry:
+::0:0::
This entry is used by NIS client hosts to indicate that they want to include NIS map information in their password files. On the NIS master server, all entries in the /etc/passwd file get put into the passwd NIS map. If you leave this NIS "marker" in the master server's /etc/passwd file, your NIS password file map will contain an entry for a user named +. If you do leave the entry in the password file, be sure to put an asterisk (*) in the password field so that this "user" will not have a valid password:
+:*:0:0::
Note that this will not work under all operating systems; in particular you must not use an asterisk in SunOS 4.0 or later. If you cannot fill the password field of the NIS "marker" entry, make sure you remove this entry if you decide not to run NIS at some future point. Also, in Solaris, the plus sign entry has been deprecated in favor of the use of the Name Service Switch, via the nsswitch.conf file.
If you are using NIS to manage any local files (company phone lists, etc.), you must also make sure that your local source files are up-to-date. Once you have established the domain's name and "purified" the master server's source files, you're ready to initialize a master server. To do so, you will use the ypinit utility. You will first need to ensure that ypinit gets its naming information from files:
newmaster# cp /etc/nsswitch.files /etc/nsswitch.conf
At this point, you are quite close to creating the NIS maps via the ypinit utility. However, there is one security issue you need to be aware of. The ypinit utility will generate maps from the set of files listed in Table 3-1. One of these files is /etc/shadow, which contains a one-way hash of the password for every account name listed in /etc/passwd. If you look at /etc/shadow, you should see something like:
root:eOUqsdfpdIaiA:6445::::::
daemon:NP:6445::::::
bin:NP:6445::::::
sys:NP:6445::::::
adm:NP:6445::::::
lp:NP:6445::::::
uucp:NP:6445::::::
nuucp:NP:6445::::::
listen:*LK*:::::::
nobody:NP:6445::::::
noaccess:NP:6445::::::
nobody4:NP:6445::::::
stern:aSuxcvmyerjDM:6445::::::
mre:96wqktpdmrkjsE:6445::::::
The fields are separated by colons (:). The first field is the name of the account or login. The second field is the one-way hash. Note that the "system" accounts, except for root, have a password hash of NP or *LK*. These are not valid hashes, so the accounts are effectively locked. The nonprivileged accounts, such as stern and mre, have a valid password hash. It is safe to put the locked accounts in the NIS passwd map, because the password hash is of no use to an attacker. It is safe to put the nonprivileged accounts in the map because they don't have privileges. However, it is not safe for the root account to be put into NIS. The reason is that if an attacker obtains the hash for root, he can perform an off-line brute force attack to determine the root password of the master NIS server. With that password, the attacker could render havoc on your network.
Thus, you must take steps to ensure that the passwd map does not have a root entry. The ypinit utility will invoke the make utility on /var/yp/Makefile. Then Makefile will by default get the passwd map contents from /etc/passwd and /etc/shadow, but by setting the PWDIR Makefile variable to something else, you can ensure that ypinit will create the passwd