| ## A Tutorial
## Jeroen Ruigrok van der Werven <>
Centralized management with Unix workstations and servers is hard to
accomplish. At least, it was. Using NIS is a step closer towards
some ordering in the chaos that can emerge from a crowded LAN.
NIS? What is that? NIS is a product developed by Sun Microsystems,
and the acronym stands for Network Information Service. Well, it is
the new name Sun gave it as it was formerly know as Yellow Pages (YP),
but YP is trademarked but British Telecom, so the name had to be
What can NIS do?
NIS allows a networked environment of Unix boxen to share common
authentication files, such as /etc/group, the password file on your
version of Unix (in the case of FreeBSD: /etc/passwd) and a lot of
NIS is an extremely handy solution in a large networked environment
in which a lot of users need to be able to log in on every available
station without having to worry about whether or not the user has an
account on that workstation.
The above example works even better in conjunction with the Network
File System, since this allows the user to be able to use his home
directory wherever he logs in.
Requisites for NIS
NIS, as may be obvious from the name, at least needs to have a
working network environment (which could also be the Internet) to make
effective use of it.
Furthermore, since you, the reader, obviously read this because you
are curious about how to set it up on your own systems I will assume
that I should not have to dwell too long on the subjects of basic IP
I cannot stress it enough, but I will say it again, define a policy
on what rights certain type of users get. This is one of the most
underestimated things in administration. Whatever damage done to your
system(s) by individuals able to acquire root privilege will always be
the responsibility of the administrators. Therefore, know what you
are dealing with by playing with it in a test environment before
implementing it at large since NIS was/is known for having security
flaws (which has been compensated a lot for by NIS+).
The security policy settled, we need to know something very
important; which server will be the master server? Make sure this
server can handle the requests send against it.
Another important thing to think about is name giving of the servers
and the domain. The easiest way to do this is using the same names as
those in use by DNS (provided one uses DNS of course). The NIS domain
name should be identical to the DNS domain name, but isn't required to
(but will surely save you a lot of administrative headaches in the
Setting up the Master Server
Obviously, since NIS is a centralized approach towards administration
we need start our configuration on the master server. I will assume
that you have installed a very normal FreeBSD box, nothing fancy.
On that server, verify that we have not yet set a NIS domain name by
If the server has no domain name it will echo a blank line and then
the command prompt again.
If we want to set a domain name we would su to root and type
something like this:
# domainname foo
Typing domainname again on a new line will now echo the domain name
back to us:
NOTE: this will only set up the domain name for as long as the server
is up. If you want to make the domain name a permanent addition to
the server start-up do the following as root:
# vi /etc/rc.conf
[ Look for the `nisdomain' line in that file, it's probably
set to NO, then change it to the domain name for your NIS
nisdomainname="foo" # Set to NIS domain if using NIS (or NO).
Then save the file.
The above steps took care of the NIS domain name, but of course
there's more to do to the server before it's truly a master. We are
currently settling on only one NIS server, so we won't need to enable
pushing (of the server data to slave servers). But regardless of the
servers involved, we are required to create a file called ypservers in
/var/yp to let the system know which hosts are NIS servers. This file
needs to know about the servers, so we simply create a file in /var/yp
called ypservers in which we place the hostnames of the servers
involved. We now need to initialize some files for the domain. We
need to copy the master.passwd to /var/yp and then get rid of any
administrator accounts such as root and toor or any other UID 0
users. Then we run a make in /var/yp:
# cd /var/yp
# vi ypservers
[ add server(s) and save ]
# cp -p /etc/master.passwd .
# ls -alsoF
1 drwxr-xr-x 2 root wheel - 512 Feb 15 02:29 ./
1 drwxr-xr-x 19 root wheel - 512 Dec 30 23:18 ../
18 -r--r--r-- 1 root wheel - 18126 Feb 15 02:29 Makefile.dist
2 -rw------- 1 root wheel - 1237 Feb 16 21:38 master.passwd
0 -rw-r--r-- 1 root wheel - 0 Feb 16 20:41 ypservers
# cp -p Makefile.dist Makefile
[ this will make the current domain, if you need to make
another domain, use make target domainname ]
NOTE: it will generate some errors with regard to ypserv not being
active. This can be solved by running ypserv as root before starting
If we would look at the directory structure right now we would see
that the make process has created a passwd file and a directory with
the domain name.
So now that we got the maps set up in /var/yp we need to enable
lookups to work in the domain. This is done by editing /etc/host.conf
and removing the # which precedes the nis entry.
Now for the clients and the slave servers to be able to be looked up
we would need entries for them in either DNS or /etc/hosts. Basically
in my opinion if one uses DNS why bother with /etc/hosts, it will only
mean double administration.
To be sure that NIS is started every time we have to reboot the
machine for whatever reason we have to edit /etc/rc.conf a final time.
In rc.conf there is a special section titled Network Information
Services (NIS), we need to edit this section.
This is the line that primarily concerns us (since we have already
set the NIS domain earlier on):
nis_server_enable="NO" # We're an NIS server (or NO).
We need to change this to:
nis_server_enable="YES" # We're an NIS server (or NO).
Since we have copied and edited master.passwd in /var/yp we also want
to enable yppasswdd and set the flag to point to the
/var/yp/master.passwd file instead of the original master.passwd file.
In our case:
nis_yppasswdd_enable="NO" # Run rpc.yppasswdd at boot time (or NO).
nis_yppasswdd_flags="" # Flags to rpc.yppasswdd (if enabled).
We are going to change this to:
nis_yppasswdd_enable="YES" # Run rpc.yppasswdd at boot time (or NO).
nis_yppasswdd_flags="-t /var/yp/master.passwd" # Flags to rpc.yppasswdd (if enabled).
[ NOTE: for more verbose logging put -v in the yppasswdd flags ]
The reason I use /var/yp/master.passwd and not the /etc/master.passwd
is because I have deleted all the UID 0 and other important accounts
that could be used for compromises.
Another thing to address, since we are a single master server we have
no need to fill in the ypxfrd lines since these are only used for
transferring maps to the slave servers.
At this point we might want to reboot to see if all has been well.
Please be patient at boot-up as my P166-MMX took 2.5 minutes before it
Client Side Installation of NIS
So we made it through the server part, now we want to be able to use
the master as well as a client and we want a host to use the NIS
domain as well.
Most of the client-side configuration takes place in /etc/rc.conf.
The first is the obvious one, namely nisdomainname, this must be set
to the domain which it will primarily use.
nisdomainname="foo" # Set to NIS domain if using NIS (or NO).
Next we need to enable the ypbind daemon to make sure the host will
be a NIS client.
nis_client_enable="YES" # We're an NIS client (or NO).
nis_client_flags="" # Flags to ypbind (if enabled).
If we don't provide client flags the client will use the
nisdomainname and will send out a broadcast for a server that serves
that domain. This might be considered a security hole since anyone
can configure a server to respond to the NIS domain being broadcast.
If this is deemed insecure by you then I suggest you take a look at
man ypbind and especially it's -S flag. If we would apply it here we
would get something like this:
nis_client_flags="-S foo,server1,server2" # Flags to ypbind (if enabled).
[ NOTE: the server names have to be able to resolve to IP
addresses, either by /etc/hosts or else DNS ]
Next thing to do on the client would be to edit master.passwd, group
and some other file to enable NIS to use them.
Delete groups which are not system critical like games and append
+::: at the end of the file (this will signify to use NIS).
/etc/master.passwd and passwd
Use vipw to delete all users not needed for system operation, such as
UIDs starting at 1000 and onwards, user games, etc. Append a
+::::::::: to the end of the file to enable NIS. If one combines NIS
with NFS this will mean that whatever the host on which the user logs
in, he always has his home directory.
The order of the lookups, I myself use bind, then nis, then hosts on
the clients. Some people prefer to swap hosts and bind. This is
something that reflects your own personal choices. I just know my DNS
servers work =)
[ NOTE: with bind at the top, ypwhich should return the
complete DNS host and domain name ]
Add the necessary entries such as the NIS servers, and append a +::
to enable NIS.
You can now either reboot or just do a domainname followed by ypbind
as root to enable NIS. Now try to login on that client host with a
user name not present locally, but which you know exists on the NIS
Another test would be to use ypmatch like this:
ypmatch user master.passwd
This will search the NIS password file for the user and print the
You now have a working NIS domain structure. If you find any errors
in the text above please do not hesitate to mail me, but be sure to
have tested it thoroughly first and have read the text and understood
Thanks go to John Kenagy for his NIS document and help on
freebsd-questions as well as Ted Wisniewski's document from which I
learned a lot to set up NIS.
Return to Issue #3