server for updating NIS passwords
master.passwd template file
utility allows users to
change their NIS passwords and certain other information using the
utility is an
RPC-based server that accepts incoming password change requests, authenticates
them, places the updated information in the
template file and
then updates the NIS master.passwd
utility allows a normal NIS
user to change his or her NIS password, full name (also known as 'GECOS'
field) or shell. These updates are typically done using the
commands. (Some administrators do not want users to be able to change their
full name information or shells; the server can be invoked with option flags
that disallow such changes.) When the server receives an update request, it
compares the address of the client making the request against the
rules outlined in
. (See the
manual page for more information on securenets; the
utility uses the same access
control mechanism as
The server then checks the 'old' password supplied by the user to make sure it
is valid, then performs some sanity checks on the updated information (these
include checking for embedded control characters, colons or invalid shells).
Once it is satisfied that the update request is valid, the server modifies the
template password file (the default is
) and then runs the
script to rebuild
the NIS maps. (This script has two arguments passed to it: the absolute
pathname of the password template that was modified and the name of the domain
that is to be updated. These in turn are passed to
also allows the super-user on
the NIS master server to perform more sophisticated updates on the NIS passwd
maps. The super-user can modify any field in any user's master.passwd entry in
any domain, and can do so without knowing the user's existing NIS password
(when the server receives a request from the super-user, the password
authentication check is bypassed). Furthermore, if the server is invoked with
flag, the super-user can even add
new entries to the maps using
Again, this only applies to the super-user on the NIS master server: none of
these special functions can be performed over the network.
utility can only be run on
a machine that is an NIS master server.
The following options are available:
master.passwd template file
- By default,
rpc.yppasswdd assumes that
the template file used to generates the
passwd maps for the default domain is
called /var/yp/master.passwd. This
default can be overridden by specifying an alternate file name with the
Note: if the template file specified with this flag is
rpc.yppasswdd will also automatically
to rebuild the local password databases in addition to the NIS maps.
rpc.yppasswdd utility can support
multiple domains, however it must choose one domain as a default. It will
try to use the system default domain name as set by the
command for this default. However, if the system domain name is not set, a
default domain must be specified on the command line. If the system
default domain is set, then this option can be used to override it.
- This option can be used to override the default path to the location of
the NIS map databases. The compiled-in default path is
- Disallow changing of shell information.
- Disallow changing of full name ('GECOS') information.
- Allow additions to be made to the NIS passwd databases. The super-user on
the NIS master server is permitted to use the
command to perform unrestricted modifications to any field in a user's
master.passwd map entry. When
rpc.yppasswdd is started with this
flag, it will also allow the super-user to add new records to the NIS
passwd maps, just as is possible when using
to modify the local password database.
- Turn on multi-domain mode. Even though
can handle several simultaneous domains, most implementations of
rpc.yppasswdd can only operate on a
single NIS domain, which is generally the same as the system default
domain of the NIS master server. The FreeBSD
rpc.yppasswdd attempts to overcome this
problem in spite of the inherent limitations of the
yppasswd protocol, which does not allow
for a domain argument in client
requests. In multi-domain mode,
rpc.yppasswdd will search through all
the passwd maps of all the domains it can find under
/var/yp until it finds an entry that
matches the user information specified in a given update request. (Matches
are determined by checking the username, UID and GID fields.) The matched
entry and corresponding domain are then used for the update.
Note that in order for multi-domain mode to work, there have to be separate
template files for each domain. For example, if a server supports three
baz, there should be three separate
master.passwd template files called
foo happens to be the system default
domain, then its template file can be either
/var/yp/master.passwd. The server will
check for the latter file first and then use the former if it cannot find
Multi-domain mode is off by default since it can fail if there are duplicate
or near-duplicate user entries in different domains. The server will abort
an update request if it finds more than one user entry that matches its
search criteria. Even so, paranoid administrators may wish to leave
multi-domain mode disabled.
rpc.yppasswdd is invoked with this
flag, it will perform map updates in place. This means that instead of
just modifying the password template file and starting a map update, the
server will modify the map databases directly. This is useful when the
password maps are large: if, for example, the password database has tens
of thousands of entries, it can take several minutes for a map update to
complete. Updating the maps in place reduces this time to a few
- Turn on verbose logging mode. The server normally only logs messages using
facility when it encounters an error condition, or when processing updates
for the super-user on the NIS master server. Running the server with the
-v flag will cause it to log
informational messages for all updates.
- Many commercial
clients do not use a reserved port when sending requests to
rpc.yppasswdd. This is either because
program is not installed set-uid root, or because the RPC implementation
does not place any emphasis on binding to reserved ports when establishing
client connections for the super-user. By default,
rpc.yppasswdd expects to receive
requests from clients using reserved ports; requests received from
non-privileged ports are rejected. Unfortunately, this behavior prevents
any client systems that to not use privileged ports from successfully
submitting password updates. Specifying the
-u flag to
rpc.yppasswdd disables the privileged
port check so that it will work with
clients that do not use privileged ports. This reduces security to a
certain small degree, but it might be necessary in cases where it is not
possible to change the client behavior.
- Display the list of flags and options understood by
- The script invoked by
update and push the NIS maps after an update.
- The template password file for the default domain.
- The NIS maps for a particular NIS domain.
- The template password file(s) for non-default domains (used only in
As listed in the yppasswd.x protocol definition, the YPPASSWDPROC_UPDATE
procedure takes two arguments: a V7-style passwd structure containing updated
user information and the user's existing unencrypted (cleartext) password.
is supposed to handle
update requests from remote NIS client machines, this means that
and similar client programs will in fact be transmitting users' cleartext
passwords over the network.
This is not a problem for password updates since the plaintext password sent
with the update will no longer be valid once the new encrypted password is put
into place, but if the user is only updating his or her 'GECOS' information or
shell, then the cleartext password sent with the update will still be valid
once the update is completed. If the network is insecure, this cleartext
password could be intercepted and used to gain unauthorized access to the