With the growing size of today's networks and the publicity
Internet has been receiving, administrators not only
need tools to
quickly and easily administer their networks, they need
will assist in the security of their networks. The new
offered in Sunsoft's Network Information Service Plus
a system administrator with the ability to protect information
their namespace from unauthorized access. Any tool which
both ease of administration and security is extremely
if it is bundled with the operating system. To my knowledge,
are no other operating systems that come bundled with
a naming service
with this level of security. In this article I discuss
within a network is protected from unauthorized access
as well as
the steps and tools administrators can use to secure
NIS+ Security Features
Several new security features were introduced with NIS+.
One of the
new features is the NIS+ server daemon, rpc.nisd, which
be configured to run at three different levels of security.
highest level, DES encryption is used to create keys
clients within a domain. Additional features include
group and file type permissions on all tables. Yet another
feature is that clients no longer broadcast for their
servers at boot
time. All server information is read from a startup
at boot time. All modifications to the namespace are
logged to a file,
/var/nis/<hostname>.log, so that an administrator
What Is NIS+?
Any administrator who has used the Network Information
under Solaris 1.x will be familiar with the basics of
NIS+. NIS+ and
NIS are both name services that help you distribute
or propagate information
throughout your defined namespace. The similarities
between the two
services end with that basic service. There are sixteen
tables within NIS+ (see Table 1) and you can create
as well. Instead of having to update a system file on
each host within
your network, NIS+ allows you to update a file and propagate
change throughout the entire namespace from any single
change is seen almost instantly on all systems.
Principals and Objects
Before I begin discussing the mechanics of security
within NIS+, it
will help to define the terms used within the name service.
within NIS+ consists of two things, principals and objects.
is an entity within the namespace which requests information.
can be either a user or a workstation where both are
known as clients,
with the latter usually being the root user on the workstation.
are structures which contain information pertaining
to an entity within
the namespace. Objects within NIS+ include directories,
and groups. A user, who is a principal, requests information
within a table, which is an object. Whether or not the
receive the information is the basis of security within
Credentials and the Conversation Key
When the NIS+ service is running at the default security
requests for information must be authenticated in order
for the request
to be processed. Each request for information must be
by the principal's credentials in order for the request
to be authenticated.
When a principal is added to the namespace, credentials
for that principal by means of the nisaddcred command.
nisaddcred command creates two 192-bit mathematically
keys. One key is a public key which gets stored in the
table; the other is a private key which gets registered
to the keyserv
daemon upon login. The keys are generated using the
cryptography scheme. Public keys are known by all principals,
private keys are known only to the specific principal.
Credentials are part of what is known as the conversation
conversation key accompanies each request and is created
on the client
side by the keyserv daemon. The conversation key contains
a secure remote procedure call (RPC) netname, a common
key, and an encrypted timestamp and time window. The
the secure RPC netname, in the format of <unix.UID@domainname>,
the cred table within NIS+. The common key is generated
using the client's private key and the server's public
from the NIS_COLD_START file. A DES-encrypted timestamp
time window are combined with the common key and netname
forward to the server. The server, knowing its own private
the principal's public key, uses these to decrypt the
key from the client. If the keys are decrypted successfully,
is then authenticated. Unknown to the client, every
request for information
NIS+ security can best be described by two terms, authentication
authorization. Authentication is the process of a principal
his or her credibility. Authentication is effected by
a server examining
the credentials passed by the client. Credentials are
the means by
which a principal is authenticated. Each request for
must be accompanied by the principal's credentials.
Once a principal is authenticated, what is the principal
to see? There are four classes of principals within
NIS+: owner, group,
world, and nobody. The first three classes are similar
to UNIX owner,
group, and world permissions for files and directories.
Each of the
four classes provides four access rights to the objects/tables:
modify, create, and destroy. Table 2 shows the default
for the tables within a domain. It should be noted that
for nobody are listed first, then owner, group, and
world. A server
examines the appropriate permissions of the object based
on the request
from the authenticated principal and returns the information
principal is authorized.
A special case arises in unauthenticated requests. This
is the case
where the server was unable to identify the principal
as a "known"
client. The principal class of "nobody" is
assigned to all
unauthenticated requests and the server grants or denies
based on the authorizations of the object for class
nobody. Figure 1
illustrates the authentication and authorization process.
Levels of Security
The daemon which runs on all servers within the namespace,
can be run at three levels of security. You specify
the level by supplying
the "-S <level>" option. Level 0 is
the lowest level and provides
no security. At this level any principal can obtain,
change, or destroy
information within the namespace. Level 1 security accepts
and DES credentials. The principal must have LOCAL credentials
the cred table in order to be authenticated. Level 2,
highest and default level, uses DES credentials. Only
have valid DES credentials are authenticated. The rpc.nisd
daemon is started from the /etc/init.d/rpc (/etc/rc2.d/S71rpc)
script at run level 2. You can modify this file if you
wish to run
the rpc.nisd daemon at a level other than level two,
is not recommended.
NIS+ groups are very similar to UNIX-style groups. Each
have an owner and group assigned. Information about
a domain's groups
is stored within the /var/nis/<server>/group_dir
Just as UNIX files have owner and group permissions,
NIS+ tables have
the same. However, groups in the /etc/group file or
NIS+ group table are not the same as NIS+ groups. NIS+
must be created separately from the UNIX groups. With
of NIS+ groups, an administrator can selectively assign
or users the ability to read, modify, create, or destroy
tables on the basis of group permissions. For example,
a group, useradm,
could be created and assigned to the passwd and group
tables. Users added to the group would then automatically
permission to modify those tables.
All of the commands within NIS+ are prefaced with "nis".
Some of the more basic commands with which UNIX administrators
be familiar are niscat, nischgrp, nischmod,
nischown, nisls, and nispasswd. All of the
above commands operate like their UNIX counterparts,
except that the
operation is performed on an NIS+ object. Just as chown,
chgrp, and chmod can be used to tighten security on
UNIX files and directories, so can nischown, nischmod,
and nischgrp on NIS+ objects.
Two specific administrative commands are nistbladm and
As their names suggest the first deals with table administration
the second deals with group administration. Nistbladm
an administrator the ability to create (-c), delete
(-d), and modify
(-m) tables and entries. Nisgrpadm provides the ability
create (-c) and delete (-d) groups as well as add (-a)
(-r) principals to specific groups.
The command which deals specifically with credentials
When you use the nisserver script to set up servers,
is run automatically to add credentials for all known
the domain. Figure 2 shows the nisaddcred command. A
key gets registered when the principal logs into his/her
The login program has been modified to automatically
do a keylogin.
If the principal's UNIX and network passwords are identical,
will be registered. If the principal's UNIX and network
differ, the principal can manually use keylogin to register
the key. If the principal's key is not registered, requests
be authenticated. The command chkey can be used to synchronize
the UNIX and network password. Nisaddcred can also be
to remove (-r) credentials for a specific principal.
A few other commands of interest are nisshowcache, nischttl,
nislog, and nisdefaults. Nisshowcache shows
the contents of a client's cache, while nisdefaults
the default parameters for a principal. Nischttl allows
administrator to change the time to live values for
while nislog command allows viewing of the transaction
NIS+ is a completely different application from NIS.
If your environment
doesn't require security for your network information,
not be what you need. I suggest that you read more about
of NIS+ and plan carefully before proceeding with setting
up a namespace.
This article is not meant to suggest that using NIS+
protect your system from unauthorized access. Rather,
NIS+ is just
one more tool to be used in securing your network.
About the Author
Andy Papp is a Senior Systems Analyst with Computer
Corporation under contract at NASA Langley Research
Center in Hampton,
VA. Andy has a B.S. in Computer Science from Old Dominion
and is currently working on his Master's, also at Old
has been working with UNIX for seven years and is a
Education certified instructor in several administration
Andy can be reached electronically at firstname.lastname@example.org.