About the author:Frédéric
Raynal is writing his thesis in informatics at the INRIA. He likes to read (Tolkien as well
as Balzac) and to listen to music (from Mozart to Philip Glass and
from Led Zeppelin to Massive Attack over Björk and Boris Vian,
but carefully avoiding rap, techno and some other kinds of noise
;-)
Content:

Yellow Pages 2 : The client side

Abstract:

The previous article was an introduction to the basic concepts of
yellow pages (YPs). In this one, we will see how to
configure your client, a practical example showing how the client
works and a presentation of the different tools that come along. At
the end, we will say something about NIS+

Introduction

The client side of services connected to yellow pages is
essentially based on the ypbind daemon: it sends the requests
to the YP server. We will first explain how it works and how to
configure it. After that, we will also see how the NIS protocol
works. The last part of the article is dedicated to the different
client side tools of YP (yp-tools).

Configuring your NIS client

The only action needed to run an NIS client on a machine is to run
the ypbind daemon.

ypbind

ypbind establishes a
link between the client and the NIS server. This link is visible in
the directory /var/yp/binding1 in the file that's usually named
domainname.version. The only supported version at the time being is
version 2. So, if my NIS domain name is "messiah", the file name
will be messiah.2

The program ypbind
belongs to the super user (i.e. root), consequently it has to be
located in /sbin, or in /usr/sbin.

When run, ypbind will go
and find its instructions in the file /etc/yp.conf. This file consists of
the following:

domain nisdomain server hostname : the client
will look for hostname for the domain nisdomain
;

ypserver hostname : the client addresses
hostname directly for the local domain. In this
configuration, the server's IP address has to be included in
/etc/hosts.

If this configuration file is wrong or if it doesn't exist,
ypbind will
broadcast2 a search on
the local network for the NIS server of the local domain.

Some basic actions allow us to verify that ypbind is configured correctly.

create your file /etc/yp.conf ;

verify that portmap
is working (ps aux | grep portmap). If it isn't, we want to
launch it. This program associates the computer's TCP/IP ports
(or UDP/IP) with the programs. During the initialization of an
RPC server, it signals to portmap the ports it is listening on
and the program numbers it wants to launch. When a client emits
an RPC request to a given program number, it will first contact
portmap to know which
port the RPC packets have to be sent. This explanation shows that
it is necessary to have portmap running beforeypbind ;

create the directory /var/yp ;

launch ypbind ;

use the command rpcinfo to make sure that ypbind is working correctly :

Executing a "rpc -p localhost" should give you the
following information :

program

vers

proto

port

100000

2

tcp

111

portmapper

100000

2

udp

111

portmapper

100007

2

tcp

637

ypbind

100007

2

udp

639

ypbind

or

program

vers

proto

port

100000

2

tcp

111

portmapper

100000

2

udp

111

portmapper

100007

2

udp

758

ypbind

100007

1

udp

758

ypbind

100007

2

tcp

761

ypbind

100007

1

tcp

761

ypbind

or you can try:

"rpcinfo -u localhost ypbind" which should give you :

program 100007 version 2 ready and waiting

ou

program 100007 version 1 ready and waiting

program 100007 version 2 ready and waiting

depending on the version of ypbind. The important message is
the one about version 2.

Now that ypbind is working
correctly, your machine has become an NIS client. So you can use it
to send requests to your server. For instance, "ypcat
passwd.byname" will give you all the passwords, sorted by user
name, that are present in the corresponding directory.

Last details

Some files still need some minor modifications to make the YPs work
efficiently:

/etc/host.conf : add "nis" for host lookup ;

/etc/passwd : add the following line:
+::::::
This will autorise all the users present in the server map to
connect to the client. We can refine these authorizations using
the symbols + and - to authorize or forbid access to the client.
In order to forbid the guest user, you would add the line
-guest::::::
The fields you don't want to modify, should remain empty It is
possible however to add more:
+me::::::/bin/ksh
The user "me" will use ksh instead of his/her usual shell (which
is defined in /etc/passwd of the NIS server).
As a final important note, I want to add that NIS perfectly
supports the use of netgroups3
+@sysadmins:::::::
will authorize connections of the members of the netgroup
sysadmin.

/etc/group (and/or /etc/shadow for certain versions of libc) :
like in /etc/passwd, you have to add
+:
You can also play with the group authorizations by adding + and
-

/etc/nsswitch.conf : the Network Services Switch enables us to
specify in which order the information has to be searched, in
the same way as with /etc/host.conf. The choices are:

nisplus

lookup via NIS+ (i.e. NIS version 3, a secure version
of NIS)

nis

lookup via NIS (NIS version 2, alias YPs

dns

lookup via a DNS (Domain Name Server)

files

lookup in the local files

db

lookup in the database /var/db

After each lookup option, you can use a command of the
following form
`[' ( `!'? STATUS `=' ACTION )+ `]'
where :

STATUS => "success" or "notfound" or "unavail" or
"tryagain"

ACTION => "return" or "continue"

Depending on the version of libc that is used, the lookups aren't all the
same. For instance, the shadow passwords aren't managed with
libc5. The supported services on a machine use a library
/lib/libnss_SERVICE.so.X For more information on this service,
see the man pages of nsswitch.conf

The shadow passwords on NIS are only supported
with glibc2.x. You have to remember to specify them in
nsswitch.conf

The NIS protocol

Now that our NIS client is fully operational, we will see how it
retrieves the information it needs.

When a client needs a piece of information sitting in a map of
YPs, it starts by looking for an YP server. To find one, it opens a
TCP connection to the local ypbind. The client informs it of the
domain (the NIS domain) to which it belongs and ypbind broadcasts by means of the
function RPC YPPROC_DOMAIN_NOACK. Only the NIS servers that serve this
domain respond with an ACK. The others keep silent.

ypbind sends the client
the result of the lookup (success or failure) and, if it has it,
the address of the first YP server that answered. The client can
now address the server with its request by specifying the domain,
the map, and the key.

This protocol is rather slow since it uses TCP connections. To
make things worse, it also uses a lot of sockets. To avoid this,
ypbind doesn't wait for a
client to contact it before finding the servers. In fact, it keeps a
list of servers for each domain in the file
/var/yp/binding/<domainename>.<version> and regularly
verifies whether they work properly.

yp-tools

This section briefly presents some tools of the yp-tools
package. To learn more about them you can invoke a very detailed
man page for each of these instructions ;-P

domainname : returns or fixes (depending on the option) the
NIS domain name ;

ypcat : shows the values of all the keys present in the NIS
map ;

ypmatch : shows the values of one or more keys present in an
NIS map ;

ypset : specifies which NIS server ypbind connects to ;

ypwhich : returns the name of the NIS server. With -m as an
argument followed by a map name, it returns the name of the
master map.

yppoll : takes a map as argument and returns the domain name
of the master server.

A Few Words on NIS+

Up until now we haven't spoken about a variant of NIS. On a
network, using NIS poses a great security risk. For instance, if the
NIS server is poorly protected and if a person with bad intentions
discovers:

the NIS domain name

the IP address of an NIS client

it becomes very easy to spoof (act as if it were this machine) this
machine's IP address and send a ypcat passwd to retrieve the password
list with the greatest ease. :-(

NIS+ offers an extra security layer by integrating an
authentication protocol based on the exchange of keys and it
supports data encryption.

The information is kept in tables, which are located in different
directories. Every column of a table has a header specifying, for
instance, whether the data is "case sensitive", in binary format,
etc ...

The aforementioned structure allows simply to maintain access
rights on directories and tables, and on the columns
of the tables as well. This means it is possible to prohibit access to the
password table by any user that is not authenticated on the NIS+
server. But it allows all the authenticated users access on the
entire password table, except to the field "passwd". Only the owner
of the "passwd" field can retrieve that.

There are 4 levels of security :

Nobody : The user is not authenticated ;

Owner : The user is authenticated as the owner ;

Group : The user is authenticated and belongs to a group
having access to this object ;

World : The user is authenticated but he is not the owner and
he doesn't belong to a group with access for this object .

In this configuration, root is just another user ... well,
almost ;-) If she doesn't have the proper permissions, she cannot see
the other user's passwords anymore. So she would not be able to
authenticate as an other user anymore ... but, she can still easily
perform an su :)

The data circulating on the network will not be encrypted,
except for the passwords : no password is transmitted clear text on
the network.

NIS+ is a powerful tool ... but it is hard to set up. Thorsten
Kuduk writes the following (he works on NIS, NIS+, NIS-HOWTO ... so
he knows what he is talking about ;-) :
"The choice between NIS and NIS+ is easy to make : use NIS as long
as you don't have important security needs. NIS+ is a lot more
problematic to administrate (especially on the server side)"

Conclusion

We learned how to add a new machine to an existing network,
where an NIS server is already set up. In the following article we
will see how to configure the server and how it works.

Footnotes

The exact locations of the files aren't often specified,
since they vary from one distribution to another. For instance,
to set up a ypbind daemon
started at boot time : /etc/init.d/nis, /sbin/init.d/ypclient,
/etc/rc.d/init.d/ypbind, /etc/rc.local