Network Information System (NIS/YP)

What Is It?
NIS, which stands for Network Information Services, was developed by Sun Microsystems to
centralize administration of UNIX® (originally SunOS™) systems.

It is a RPC-based client/server system that allows a group of machines within an NIS domain to
share a common set of configuration files. This permits a system administrator to set up NIS
client systems with only minimal configuration data and add, remove or modify configuration
data from a single location.

Terms/Processes You Should Know

There are several terms and several important user processes that you will come across when
attempting to implement NIS on FreeBSD, whether you are trying to create an NIS server or act
as an NIS client:

Term Description
An NIS master server and all of its clients (including its slave servers)
NIS have a NIS domainname. Similar to an Windows NT domain name,
domainname the NIS domainname does not have anything to do with DNS.

Must be running in order to enable RPC (Remote Procedure Call, a

network protocol used by NIS). If rpcbind is not running, it will be
rpcbind
impossible to run an NIS server, or to act as an NIS client.

“Binds” an NIS client to its NIS server. It will take the NIS
domainname from the system, and using RPC, connect to the server.
ypbind is the core of client-server communication in an NIS
ypbind
environment; if ypbind dies on a client machine, it will not be able to
access the NIS server.

Should only be running on NIS servers; this is the NIS server process
itself. If ypserv(8) dies, then the server will no longer be able to
respond to NIS requests (hopefully, there is a slave server to take over
for it). There are some implementations of NIS (but not the FreeBSD
ypserv one), that do not try to reconnect to another server if the server it used
before dies. Often, the only thing that helps in this case is to restart the
server process (or even the whole server) or the ypbind process on the
client.
 Term Description

Another process that should only be running on NIS master servers;

this is a daemon that will allow NIS clients to change their NIS
rpc.yppasswdd
passwords. If this daemon is not running, users will have to login to
the NIS master server and change their passwords there.

Setting Up a NIS Master Server

Setting up a master NIS server can be relatively straight forward, depending on your needs.
FreeBSD comes with support for NIS out-of-the-box. All you need is to add the following lines
to /etc/rc.conf, and FreeBSD will do the rest for you.

1. nisdomainname="test-domain"

This line will set the NIS domainname to test-domain upon network setup (e.g. after
reboot).

2. nis_server_enable="YES"

This will tell FreeBSD to start up the NIS server processes when the networking is next
brought up.

3. nis_yppasswdd_enable="YES"

This will enable the rpc.yppasswdd daemon which, as mentioned above, will allow
users to change their NIS password from a client machine.

After setting up the above entries, run the command /etc/netstart as superuser. It will set up
everything for you, using the values you defined in /etc/rc.conf. As a last step, before
initializing the NIS maps, start the ypserv daemon manually:

# /etc/rc.d/ypserv start

29.4.4.2.2 Initializing the NIS Maps

The NIS maps are database files, that are kept in the /var/yp directory. They are generated from
configuration files in the /etc directory of the NIS master, with one exception: the
/etc/master.passwd file. This is for a good reason, you do not want to propagate passwords to
your root and other administrative accounts to all the servers in the NIS domain. Therefore,
before we initialize the NIS maps, you should:
# cp /etc/master.passwd /var/yp/master.passwd

# cd /var/yp

# vi master.passwd

When you have finished, it is time to initialize the NIS maps! FreeBSD includes a script named
ypinit to do this for youBecause we are generating maps for an NIS master, we are going to
pass the -m option to ypinit. To generate the NIS maps, assuming you already performed the
steps above, run:

ellington# ypinit -m test-domain

Server Type: MASTER Domain: test-domain

Creating an YP server will require that you answer a few questions.

Questions will all be asked at the beginning of the procedure.

Do you want this procedure to quit on non-fatal errors? [y/n: n] n

Ok, please remember to go back and redo manually whatever fails.

If you don't, something might not work.

At this point, we have to construct a list of this domains YP servers.

rod.darktech.org is already known as master server.

Please continue to add any slave servers, one per line. When you are

done with the list, type a <control D>.

master server : ellington

next host to add: coltrane

next host to add: ^D

The current list of NIS servers looks like this:

ellington

coltrane

Is this correct? [y/n: y] y

[..output from map generation..]

NIS Map update completed.

ellington has been setup as an YP master server without any errors.

 ypinit should have created /var/yp/Makefile from /var/yp/Makefile.dist. When created,
this file assumes that you are operating in a single server NIS environment with only FreeBSD
machines. Since test-domain has a slave server as well, you must edit /var/yp/Makefile:

ellington# vi /var/yp/Makefile

You should comment out the line that says

NOPUSH = "True"

Setting up a NIS Slave Server

Setting up an NIS slave server is even more simple than setting up the master. Log on to the
slave server and edit the file /etc/rc.conf as you did before. The only difference is that we
now must use the -s option when running ypinit. The -s option requires the name of the NIS
master be passed to it as well, so our command line looks like:

coltrane# ypinit -s ellington test-domain

Server Type: SLAVE Domain: test-domain Master: ellington

Creating an YP server will require that you answer a few questions.

Questions will all be asked at the beginning of the procedure.

Do you want this procedure to quit on non-fatal errors? [y/n: n] n

Ok, please remember to go back and redo manually whatever fails.

If you don't, something might not work.

There will be no further questions. The remainder of the procedure

should take a few minutes, to copy the databases from ellington.

Transferring netgroup...

ypxfr: Exiting: Map successfully transferred

Transferring netgroup.byuser...

ypxfr: Exiting: Map successfully transferred

Transferring netgroup.byhost...

ypxfr: Exiting: Map successfully transferred

Transferring master.passwd.byuid...

ypxfr: Exiting: Map successfully transferred

Transferring passwd.byuid...

ypxfr: Exiting: Map successfully transferred

Transferring passwd.byname...

ypxfr: Exiting: Map successfully transferred

Transferring group.bygid...

ypxfr: Exiting: Map successfully transferred

Transferring group.byname...

ypxfr: Exiting: Map successfully transferred

Transferring services.byname...

ypxfr: Exiting: Map successfully transferred

Transferring rpc.bynumber...

ypxfr: Exiting: Map successfully transferred

Transferring rpc.byname...

ypxfr: Exiting: Map successfully transferred

Transferring protocols.byname...

ypxfr: Exiting: Map successfully transferred

Transferring master.passwd.byname...

ypxfr: Exiting: Map successfully transferred

Transferring networks.byname...

ypxfr: Exiting: Map successfully transferred

Transferring networks.byaddr...

ypxfr: Exiting: Map successfully transferred

Transferring netid.byname...

ypxfr: Exiting: Map successfully transferred

Transferring hosts.byaddr...

ypxfr: Exiting: Map successfully transferred

Transferring protocols.bynumber...

ypxfr: Exiting: Map successfully transferred

Transferring ypservers...

ypxfr: Exiting: Map successfully transferred

 Transferring hosts.byname...

ypxfr: Exiting: Map successfully transferred

coltrane has been setup as an YP slave server without any errors.

Don't forget to update map ypservers on ellington.

You should now have a directory called /var/yp/test-domain. Copies of the NIS master
server's maps should be in this directory. You will need to make sure that these stay updated. The
following /etc/crontab entries on your slave servers should do the job:

20 * * * * root /usr/libexec/ypxfr
passwd.byname

21 * * * * root /usr/libexec/ypxfr passwd.byuid

These two lines force the slave to sync its maps with the maps on the master server. Although
these entries are not mandatory, since the master server attempts to ensure any changes to its NIS
maps are communicated to its slaves and because password information is vital to systems
depending on the server, it is a good idea to force the updates. This is more important on busy
networks where map updates might not always complete.

Now, run the command /etc/netstart on the slave server as well, which again starts the NIS
server.

NIS Clients

An NIS client establishes what is called a binding to a particular NIS server using the ypbind
daemon. ypbind checks the system's default domain (as set by the domainname command), and
begins broadcasting RPC requests on the local network. These requests specify the name of the
domain for which ypbind is attempting to establish a binding. If a server that has been
configured to serve the requested domain receives one of the broadcasts, it will respond to
ypbind, which will record the server's address. If there are several servers available (a master
and several slaves, for example), ypbind will use the address of the first one to respond. From
that point on, the client system will direct all of its NIS requests to that server. ypbind will
occasionally “ping” the server to make sure it is still up and running. If it fails to receive a reply
to one of its pings within a reasonable amount of time, ypbind will mark the domain as unbound
and begin broadcasting again in the hopes of locating another server.

Setting Up a NIS Client

 Setting up a FreeBSD machine to be a NIS client is fairly straightforward.

1. Edit the file /etc/rc.conf and add the following lines in order to set the NIS
domainname and start ypbind upon network startup:

nisdomainname="test-domain"

nis_client_enable="YES"

2. To import all possible password entries from the NIS server, remove all user
accounts from your /etc/master.passwd file and use vipw to add the following
line to the end of the file:

+:::::::::

3.To import all possible group entries from the NIS server, add this line to your
/etc/group file:

+:*::

To start the NIS client immediately, execute the following commands as the superuser:

# /etc/netstart

# /etc/rc.d/ypbind start

After completing these steps, you should be able to run ypcat passwd and see the NIS
server's passwd map.

4.5 NIS Security

In general, any remote user can issue an RPC to ypserv(8) and retrieve the contents of your NIS
maps, provided the remote user knows your domainname. To prevent such unauthorized
transactions, ypserv(8) supports a feature called “securenets” which can be used to restrict access
to a given set of hosts. At startup, ypserv(8) will attempt to load the securenets information from
a file called /var/yp/securenets.

# allow connections from local host -- mandatory

127.0.0.1 255.255.255.255

# allow connections from any host

# on the 192.168.128.0 network

192.168.128.0 255.255.255.0
 # allow connections from any host

# between 10.0.0.0 to 10.0.15.255

# this includes the machines in the testlab

10.0.0.0 255.255.240.0

If ypserv(8) receives a request from an address that matches one of these rules, it will process the
request normally. If the address fails to match a rule, the request will be ignored and a warning
message will be logged. If the /var/yp/securenets file does not exist, ypserv will allow
connections from any host.

The ypserv program also has support for Wietse Venema's TCP Wrapper package. This allows
the administrator to use the TCP Wrapper configuration files for access control instead of
/var/yp/securenets.

Note: While both of these access control mechanisms provide some security, they, like the
privileged port test, are vulnerable to “IP spoofing” attacks. All NIS-related traffic should be
blocked at your firewall.

Servers using /var/yp/securenets may fail to serve legitimate NIS clients with archaic TCP/IP
implementations. Some of these implementations set all host bits to zero when doing broadcasts
and/or fail to observe the subnet mask when calculating the broadcast address. While some of
these problems can be fixed by changing the client configuration, other problems may force the
retirement of the client systems in question or the abandonment of /var/yp/securenets.

Using /var/yp/securenets on a server with such an archaic implementation of TCP/IP is a

really bad idea and will lead to loss of NIS functionality for large parts of your network.

The use of the TCP Wrapper package increases the latency of your NIS server. The additional
delay may be long enough to cause timeouts in client programs, especially in busy networks or
with slow NIS servers. If one or more of your client systems suffers from these symptoms, you
should convert the client systems in question into NIS slave servers and force them to bind to
themselves.

Barring Some Users from Logging On

In our lab, there is a machine basie that is supposed to be a faculty only workstation. We do not
want to take this machine out of the NIS domain, yet the passwd file on the master NIS server
contains accounts for both faculty and students. What can we do?

There is a way to bar specific users from logging on to a machine, even if they are present in the
NIS database. To do this, all you must do is add -username to the end of the
/etc/master.passwd file on the client machine, where username is the username of the user
you wish to bar from logging in. This should preferably be done using vipw, since vipw will
 sanity check your changes to /etc/master.passwd, as well as automatically rebuild the
password database when you finish editing. For example, if we wanted to bar user bill from
logging on to basie we would:

basie# vipw

[add -bill to the end, exit]

vipw: rebuilding the database...

vipw: done

basie# cat /etc/master.passwd

root:[password]:0:0::0:0:The super-user:/root:/bin/csh

toor:[password]:0:0::0:0:The other super-user:/root:/bin/sh

daemon:*:1:1::0:0:Owner of many system processes:/root:/sbin/nologin

operator:*:2:5::0:0:System &:/:/sbin/nologin

bin:*:3:7::0:0:Binaries Commands and Source,,,:/:/sbin/nologin

tty:*:4:65533::0:0:Tty Sandbox:/:/sbin/nologin

kmem:*:5:65533::0:0:KMem Sandbox:/:/sbin/nologin

games:*:7:13::0:0:Games pseudo-user:/usr/games:/sbin/nologin

news:*:8:8::0:0:News Subsystem:/:/sbin/nologin

man:*:9:9::0:0:Mister Man Pages:/usr/share/man:/sbin/nologin

bind:*:53:53::0:0:Bind Sandbox:/:/sbin/nologin

uucp:*:66:66::0:0:UUCP pseudo-
user:/var/spool/uucppublic:/usr/libexec/uucp/uucico

xten:*:67:67::0:0:X-10 daemon:/usr/local/xten:/sbin/nologin

pop:*:68:6::0:0:Post Office Owner:/nonexistent:/sbin/nologin

nobody:*:65534:65534::0:0:Unprivileged user:/nonexistent:/sbin/nologin

+:::::::::

-bill

basie#

Important Things to Remember

There are still a couple of things that you will need to do differently now that you are in an NIS
environment.
 Every time you wish to add a user to the lab, you must add it to the master NIS
server only, and you must remember to rebuild the NIS maps. If you forget to do
this, the new user will not be able to login anywhere except on the NIS master. For
example, if we needed to add a new user jsmith to the lab, we would:

 # pw useradd jsmith

 # cd /var/yp

 # make test-domain

You could also run adduser jsmith instead of pw useradd jsmith.

 Keep the administration accounts out of the NIS maps. You do not want to be
propagating administrative accounts and passwords to machines that will have
users that should not have access to those accounts.
 Keep the NIS master and slave secure, and minimize their downtime. If somebody
either hacks or simply turns off these machines, they have effectively rendered
many people without the ability to login to the lab.

This is the chief weakness of any centralized administration system. If you do not
protect your NIS servers, you will have a lot of angry users!