30.4. Network Information System
(NIS)
Network Information System (NIS) is
designed to centralize administration of UNIX®-like systems
such as Solaris™, HP-UX, AIX®, Linux, NetBSD, OpenBSD, and
FreeBSD. NIS was originally known as Yellow
Pages but the name was changed due to trademark issues. This
is the reason why NIS commands begin with
yp.
NIS is a Remote Procedure Call
(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 to add, remove,
or modify configuration data from a single location.
FreeBSD uses version 2 of the NIS
protocol.
30.4.1. NIS Terms and Processes
Table 28.1 summarizes the terms and important processes
used by NIS:
Table 30.1.
NIS Terminology
| Term | Description |
|---|
| NIS domain name | NIS servers and clients share
an NIS domain name. Typically,
this name does not have anything to do with
DNS. |
| rpcbind(8) | This service enables RPC and
must be running in order to run an
NIS server or act as an
NIS client. |
| ypbind(8) | This service binds an NIS
client to its NIS server. It will
take the NIS domain name and use
RPC to connect to the server. It
is the core of client/server communication in an
NIS environment. If this service
is not running on a client machine, it will not be
able to access the NIS
server. |
| ypserv(8) | This is the process for the
NIS server. If this service stops
running, the server will no longer be able to respond
to NIS requests so hopefully, there
is a slave server to take over. Some non-FreeBSD clients
will not try to reconnect using a slave server and the
ypbind process may need to
be restarted on these
clients. |
| rpc.yppasswdd(8) | This process only runs on
NIS master servers. This daemon
allows NIS clients to change their
NIS passwords. If this daemon is
not running, users will have to login to the
NIS master server and change their
passwords there. |
There are three types of hosts in an
NIS environment:
NIS master server
This server acts as a central repository for host
configuration information and maintains the
authoritative copy of the files used by all of the
NIS clients. The
passwd, group,
and other various files used by NIS
clients are stored on the master server. While it is
possible for one machine to be an NIS
master server for more than one NIS
domain, this type of configuration will not be covered in
this chapter as it assumes a relatively small-scale
NIS environment.
NIS slave servers
NIS slave servers maintain copies
of the NIS master's data files in
order to provide redundancy. Slave servers also help to
balance the load of the master server as
NIS clients always attach to the
NIS server which responds
first.
NIS clients
NIS clients authenticate
against the NIS server during log
on.
Information in many files can be shared using
NIS. The
master.passwd,
group, and hosts
files are commonly shared via NIS.
Whenever a process on a client needs information that would
normally be found in these files locally, it makes a query to
the NIS server that it is bound to
instead.
30.4.3. Planning Considerations
This section describes a sample NIS
environment which consists of 15 FreeBSD machines with no
centralized point of administration. Each machine has its own
/etc/passwd and
/etc/master.passwd. These files are kept
in sync with each other only through manual intervention.
Currently, when a user is added to the lab, the process must
be repeated on all 15 machines.
The configuration of the lab will be as follows:
If this is the first time an NIS
scheme is being developed, it should be thoroughly planned
ahead of time. Regardless of network size, several decisions
need to be made as part of the planning process.
30.4.3.1. Choosing a NIS Domain Name
When a client broadcasts its requests for info, it
includes the name of the NIS domain that
it is part of. This is how multiple servers on one network
can tell which server should answer which request. Think of
the NIS domain name as the name for a
group of hosts.
Some organizations choose to use their Internet domain
name for their NIS domain name. This is
not recommended as it can cause confusion when trying to
debug network problems. The NIS domain
name should be unique within the network and it is helpful
if it describes the group of machines it represents. For
example, the Art department at Acme Inc. might be in the
“acme-art” NIS domain. This
example will use the domain name
test-domain.
However, some non-FreeBSD operating systems require the
NIS domain name to be the same as the
Internet domain name. If one or more machines on the
network have this restriction, the Internet domain name
must be used as the
NIS domain name.
30.4.3.2. Physical Server Requirements
There are several things to keep in mind when choosing a
machine to use as a NIS server. Since
NIS clients depend upon the availability
of the server, choose a machine that is not rebooted
frequently. The NIS server should
ideally be a stand alone machine whose sole purpose is to be
an NIS server. If the network is not
heavily used, it is acceptable to put the
NIS server on a machine running other
services. However, if the NIS server
becomes unavailable, it will adversely affect all
NIS clients.
30.4.4. Configuring the NIS Master
Server
The canonical copies of all NIS files
are stored on the master server. The databases used to store
the information are called NIS maps. In
FreeBSD, these maps are stored in
/var/yp/[domainname] where
[domainname] is the name of the
NIS domain. Since multiple domains are
supported, it is possible to have several directories, one for
each domain. Each domain will have its own independent set of
maps.
NIS master and slave servers handle all
NIS requests through ypserv(8). This
daemon is responsible for receiving incoming requests from
NIS clients, translating the requested
domain and map name to a path to the corresponding database
file, and transmitting data from the database back to the
client.
Setting up a master NIS server can be
relatively straight forward, depending on environmental needs.
Since FreeBSD provides built-in NIS support,
it only needs to be enabled by adding the following lines to
/etc/rc.conf:
nisdomainname="test-domain" 
nis_server_enable="YES" 
nis_yppasswdd_enable="YES" This line sets the NIS domain name
to test-domain. | | This automates the start up of the
NIS server processes when the system
boots. |
| This enables the rpc.yppasswdd(8) daemon so that
users can change their NIS password
from a client machine. |
Care must be taken in a multi-server domain where the
server machines are also NIS clients. It
is generally a good idea to force the servers to bind to
themselves rather than allowing them to broadcast bind
requests and possibly become bound to each other. Strange
failure modes can result if one server goes down and others
are dependent upon it. Eventually, all the clients will time
out and attempt to bind to other servers, but the delay
involved can be considerable and the failure mode is still
present since the servers might bind to each other all over
again.
A server that is also a client can be forced to bind to a
particular server by adding these additional lines to
/etc/rc.conf:
nis_client_enable="YES"
nis_client_flags="-S test-domain,server" This line sets the NIS domain name
to test-domain and bind to itself. |
Since RPC is a broadcast-based service,
any system running ypbind within
the same domain can retrieve the contents of the
NIS maps. To prevent unauthorized
transactions, ypserv(8) supports a feature called
“securenets” which can be used to restrict access
to a given set of hosts. By default, this information is
stored in /var/yp/securenets, unless
ypserv(8) is started with -p and an
alternate path. This file contains entries that consist of a
network specification and a network mask separated by white
space. Lines starting with # are
considered to be comments. A sample
securenets might look like this:
# 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
securenets does not exist,
ypserv will allow connections from any
host.
Section 14.4, “TCP Wrapper” is an alternate mechanism
for providing access control instead of
securenets. While either access control
mechanism adds some security, they are both vulnerable to
“IP spoofing” attacks. All
NIS-related traffic should be blocked at
the firewall.
Servers using 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 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 these client
systems or the abandonment of
securenets.
The use of TCP Wrapper
increases the latency of the NIS server.
The additional delay may be long enough to cause timeouts in
client programs, especially in busy networks with slow
NIS servers. If one or more clients suffer
from latency, convert those clients into
NIS slave servers and force them to bind to
themselves.
30.4.7.1. Barring Some Users
In this example, the basie
system is a faculty workstation within the
NIS domain. The
passwd map on the master
NIS server contains accounts for both
faculty and students. This section demonstrates how to
allow faculty logins on this system while refusing student
logins.
To prevent specified users from logging on to a system,
even if they are present in the NIS
database, use vipw to add
-username with
the correct number of colons towards the end of
/etc/master.passwd on the client,
where username is the username of
a user to bar from logging in. The line with the blocked
user must be before the + line that
allows NIS users. In this example,
bill is barred
from logging on to basie:
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:/usr/sbin/nologin
operator:*:2:5::0:0:System &:/:/usr/sbin/nologin
bin:*:3:7::0:0:Binaries Commands and Source,,,:/:/usr/sbin/nologin
tty:*:4:65533::0:0:Tty Sandbox:/:/usr/sbin/nologin
kmem:*:5:65533::0:0:KMem Sandbox:/:/usr/sbin/nologin
games:*:7:13::0:0:Games pseudo-user:/usr/games:/usr/sbin/nologin
news:*:8:8::0:0:News Subsystem:/:/usr/sbin/nologin
man:*:9:9::0:0:Mister Man Pages:/usr/share/man:/usr/sbin/nologin
bind:*:53:53::0:0:Bind Sandbox:/:/usr/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:/usr/sbin/nologin
pop:*:68:6::0:0:Post Office Owner:/nonexistent:/usr/sbin/nologin
nobody:*:65534:65534::0:0:Unprivileged user:/nonexistent:/usr/sbin/nologin
-bill:::::::::
+:::::::::
basie#
Barring specified users from logging on to individual
systems becomes unscaleable on larger networks and quickly
loses the main benefit of NIS:
centralized administration.
Netgroups were developed to handle large, complex networks
with hundreds of users and machines. Their use is comparable
to UNIX® groups, where the main difference is the lack of a
numeric ID and the ability to define a netgroup by including
both user accounts and other netgroups.
To expand on the example used in this chapter, the
NIS domain will be extended to add the
users and systems shown in Tables 28.2 and 28.3:
Table 30.2. Additional Users
| User Name(s) | Description |
|---|
alpha,
beta | IT department employees |
charlie, delta | IT department apprentices |
echo,
foxtrott,
golf,
... | employees |
able,
baker,
... | interns |
Table 30.3. Additional Systems
| Machine Name(s) | Description |
|---|
war,
death,
famine,
pollution | Only IT employees are allowed to log onto these
servers. |
pride,
greed,
envy,
wrath,
lust,
sloth | All members of the IT department are allowed to
login onto these servers. |
one,
two,
three,
four,
... | Ordinary workstations used by
employees. |
trashcan | A very old machine without any critical data.
Even interns are allowed to use this system. |
When using netgroups to configure this scenario, each user
is assigned to one or more netgroups and logins are then
allowed or forbidden for all members of the netgroup. When
adding a new machine, login restrictions must be defined for
all netgroups. When a new user is added, the account must be
added to one or more netgroups. If the
NIS setup is planned carefully, only one
central configuration file needs modification to grant or deny
access to machines.
The first step is the initialization of the
NIS netgroup map. In
FreeBSD, this map is not created by default. On the
NIS master server, use an editor to create
a map named /var/yp/netgroup.
This example creates four netgroups to represent IT
employees, IT apprentices, employees, and interns:
IT_EMP (,alpha,test-domain) (,beta,test-domain)
IT_APP (,charlie,test-domain) (,delta,test-domain)
USERS (,echo,test-domain) (,foxtrott,test-domain) \
(,golf,test-domain)
INTERNS (,able,test-domain) (,baker,test-domain)Each entry configures a netgroup. The first column in an
entry is the name of the netgroup. Each set of brackets
represents either a group of one or more users or the name of
another netgroup. When specifying a user, the three
comma-delimited fields inside each group represent:
The name of the host(s) where the other fields
representing the user are valid. If a hostname is not
specified, the entry is valid on all hosts.
The name of the account that belongs to this
netgroup.
The NIS domain for the account.
Accounts may be imported from other NIS
domains into a netgroup.
If a group contains multiple users, separate each user
with whitespace. Additionally, each field may contain
wildcards. See netgroup(5) for details.
Netgroup names longer than 8 characters should not be
used. The names are case sensitive and using capital letters
for netgroup names is an easy way to distinguish between user,
machine and netgroup names.
Some non-FreeBSD NIS clients cannot
handle netgroups containing more than 15 entries. This
limit may be circumvented by creating several sub-netgroups
with 15 users or fewer and a real netgroup consisting of the
sub-netgroups, as seen in this example:
BIGGRP1 (,joe1,domain) (,joe2,domain) (,joe3,domain) [...]
BIGGRP2 (,joe16,domain) (,joe17,domain) [...]
BIGGRP3 (,joe31,domain) (,joe32,domain)
BIGGROUP BIGGRP1 BIGGRP2 BIGGRP3
Repeat this process if more than 225 (15 times 15) users
exist within a single netgroup.
To activate and distribute the new
NIS map:
ellington# cd /var/yp
ellington# make
This will generate the three NIS maps
netgroup,
netgroup.byhost and
netgroup.byuser. Use the map key option
of ypcat(1) to check if the new NIS
maps are available:
ellington% ypcat -k netgroup
ellington% ypcat -k netgroup.byhost
ellington% ypcat -k netgroup.byuser
The output of the first command should resemble the
contents of /var/yp/netgroup. The second
command only produces output if host-specific netgroups were
created. The third command is used to get the list of
netgroups for a user.
To configure a client, use vipw(8) to specify the
name of the netgroup. For example, on the server named
war, replace this line:
+:::::::::
with
+@IT_EMP:::::::::
This specifies that only the users defined in the netgroup
IT_EMP will be imported into this system's
password database and only those users are allowed to login to
this system.
This configuration also applies to the
~ function of the shell and all routines
which convert between user names and numerical user IDs. In
other words,
cd ~user will
not work, ls -l will show the numerical ID
instead of the username, and find . -user joe
-print will fail with the message
No such user. To fix this, import all
user entries without allowing them to login into the servers.
This can be achieved by adding an extra line:
+:::::::::/usr/sbin/nologin
This line configures the client to import all entries but
to replace the shell in those entries with
/usr/sbin/nologin.
Make sure that extra line is placed
after
+@IT_EMP:::::::::. Otherwise, all user
accounts imported from NIS will have
/usr/sbin/nologin as their login
shell and no one will be able to login to the system.
To configure the less important servers, replace the old
+::::::::: on the servers with these
lines:
+@IT_EMP:::::::::
+@IT_APP:::::::::
+:::::::::/usr/sbin/nologin
The corresponding lines for the workstations
would be:
+@IT_EMP:::::::::
+@USERS:::::::::
+:::::::::/usr/sbin/nologin
NIS supports the creation of netgroups from other
netgroups which can be useful if the policy regarding user
access changes. One possibility is the creation of role-based
netgroups. For example, one might create a netgroup called
BIGSRV to define the login restrictions for
the important servers, another netgroup called
SMALLSRV for the less important servers,
and a third netgroup called USERBOX for the
workstations. Each of these netgroups contains the netgroups
that are allowed to login onto these machines. The new
entries for the NIS
netgroup map would look like this:
BIGSRV IT_EMP IT_APP
SMALLSRV IT_EMP IT_APP ITINTERN
USERBOX IT_EMP ITINTERN USERS
This method of defining login restrictions works
reasonably well when it is possible to define groups of
machines with identical restrictions. Unfortunately, this is
the exception and not the rule. Most of the time, the ability
to define login restrictions on a per-machine basis is
required.
Machine-specific netgroup definitions are another
possibility to deal with the policy changes. In this
scenario, the /etc/master.passwd of each
system contains two lines starting with “+”.
The first line adds a netgroup with the accounts allowed to
login onto this machine and the second line adds all other
accounts with /usr/sbin/nologin as shell.
It is recommended to use the “ALL-CAPS” version
of the hostname as the name of the netgroup:
+@BOXNAME:::::::::
+:::::::::/usr/sbin/nologin
Once this task is completed on all the machines, there is
no longer a need to modify the local versions of
/etc/master.passwd ever again. All
further changes can be handled by modifying the
NIS map. Here is an example of a possible
netgroup map for this scenario:
# Define groups of users first
IT_EMP (,alpha,test-domain) (,beta,test-domain)
IT_APP (,charlie,test-domain) (,delta,test-domain)
DEPT1 (,echo,test-domain) (,foxtrott,test-domain)
DEPT2 (,golf,test-domain) (,hotel,test-domain)
DEPT3 (,india,test-domain) (,juliet,test-domain)
ITINTERN (,kilo,test-domain) (,lima,test-domain)
D_INTERNS (,able,test-domain) (,baker,test-domain)
#
# Now, define some groups based on roles
USERS DEPT1 DEPT2 DEPT3
BIGSRV IT_EMP IT_APP
SMALLSRV IT_EMP IT_APP ITINTERN
USERBOX IT_EMP ITINTERN USERS
#
# And a groups for a special tasks
# Allow echo and golf to access our anti-virus-machine
SECURITY IT_EMP (,echo,test-domain) (,golf,test-domain)
#
# machine-based netgroups
# Our main servers
WAR BIGSRV
FAMINE BIGSRV
# User india needs access to this server
POLLUTION BIGSRV (,india,test-domain)
#
# This one is really important and needs more access restrictions
DEATH IT_EMP
#
# The anti-virus-machine mentioned above
ONE SECURITY
#
# Restrict a machine to a single user
TWO (,hotel,test-domain)
# [...more groups to follow]
It may not always be advisable
to use machine-based netgroups. When deploying a couple of
dozen or hundreds of systems,
role-based netgroups instead of machine-based netgroups may be
used to keep the size of the NIS map within
reasonable limits.