Npasswd issues with NIS and password aging


Npasswd and password aging

Here is what I understand about password aging (Solaris / System 5 style).

Concepts:

From Solaris 7 man page shadow(4):

/etc/shadow is an access-restricted ASCII system file that stores users' encrypted passwords and related information. The shadow file can be used in conjunction with other shadow sources, including the NIS maps passwd.byname and passwd.byuid and the NIS+ table passwd. Programs use the getspnam(3C) routines to access this information.
       The fields are
  
       lastchg   The number of days between January 1, 1970, and
                 the date that the password was last modified.
       min       The minimum number of days required between password changes.
       max       The maximum number of days the password is valid.
       warn      The number of days before password expires that
                 the user is warned.
       inactive  The number of days of inactivity allowed for that user.
       expire    An absolute date specifying when login may no longer be used.

My comments

If ((current-time - lastchg) > max) the password has expired and the module performs a password change. The calling program knows nothing of this. The passwd program is not invoked, hence npasswd cannot be inserted in the process.

Npasswd does the following:

Npasswd, NIS and password aging

Password aging parameters are not included in the passwd file format, though the definition for struct passwd has a pw_age element, there it has no field in /etc/passwd. There can be no password aging without supplimental information.

This supplimental information is in /etc/shadow, along with the encrytped password. When NIS maps are built, the encrypted password is taken from shadow entries and included in the passwd.byname and passwd.byuid maps. The format of these maps do not include the aging information.

This means that password aging is not available on NIS clients.

From Volume 1 of Solaris 8 System Administration Guide:

If you are using NIS+ or the /etc files to store user account information, you can set up password aging on a user's password.

There is no password aging if you use NIS. If you are running NIS in C2 security mode, you get the NIS map passwd.adjunct.byname which does contain a password aging field, but it is not used.

Changing passwords on NIS clients

From the manual page for yppasswd(1m):

Entries in the passwd, shadow or passwd.adjunct files are only changed if the password presented by yppasswd(1) matches the encrypted password of the entry.

From /usr/include/rpcsvc/yppasswd.h:

	struct yppasswd {
		char *oldpass;          /* old (unencrypted) password */
		struct passwd newpw;    /* new pw structure */
	};

If npasswd detects that it is running on a NIS client (hostname != NIS master for passwd.byname), or does not find the passwd entry in any of the files in its list (but did get it from NIS), it will use the RPC interface to make the passwd change.

As detailed above, the RPC interface requires the current password be provided in cleartext. The yppasswd daemon will only work if this is given (or the target entry has a null password).

Npasswd makes the assumption that if root is changing someone else's password on a NIS client, it is because the current password is unknown. In that case, the password CANNOT be changed via the RPC interface. The only place to change an unknown password is the NIS master.

One could fault npasswd for being pendantic on this point. My experience as a system administrator is that when I am changing a users' password as root, it is because the user does not know it, hence I must make the change on the NIS master, then run the "YP make" to update the maps so the user can login.

The bottom line is that substantial user management (e.g. password changes) needs to be done on the NIS master.

Password files on NIS masters

During the process of customizing npasswd, the Configure script probes the system for password files. This list is presented and the builder is offered the option of changing it.

In the process of looking for a user entry, npasswd examines every file in this list. If the user is found and the entry is not an NIS stub (e.g. +user::0:0:::), then that file is marked as the source for the entry and the password field will be changed in that file.

Should the user not be found in any of the local files, then NIS is searched. If the user is found in NIS, then that service is marked as the source and the password will be changed via the RPC mechanism as described above.

When a file other than /etc/passwd is used as the NIS map source, that file must be in included in the password file list.

For example, if your NIS map is built from /var/yp/src/passwd, then that file must be in npasswd's internal file list.

If you attempt to change a local password on the NIS master and get the message "Information can only be changed on NIS master", then you need to redo the password file list.

To do this, run "Configure -d" and when prompted "Change passwd file list?" reply 'y' and enter the path to your NIS passwd master file. Then rebuild and install npasswd.


Last updated 05/01/01
Clyde Hoover
ACITS UNIX Services
The University of Texas at Austin