If your NIS server is HPUX and password aging is in effect it is impossible to log in. The ugly fix we hacked up locally (modifying pwdb) is to just drop all the bits after (and including) a ',' in the password field. I had intended to provide a full fix for you, but I wont be able to and I know lorax is in beta already. I didnt want this to get missed in the next release. ------------------------------------------------------------ Documentation on how the password aging fields are used in HPUX The encrypted password consists of 13 characters chosen from a 64- character set of "digits" described below, except when the password is null, in which case the encrypted password is also null. Login can be prevented by entering in the password field a character that is not part of the set of digits (such as *). The characters used to represent "digits" are . for 0, / for 1, 0 through 9 for 2 through 11, A through Z for 12 through 37, and a through z for 38 through 63. Password aging is put in effect for a particular user if his encrypted password in the password file is followed by a comma and a nonnull string of characters from the above alphabet. (Such a string must be introduced in the first instance by a superuser.) This string defines the "age" needed to implement password aging. The first character of the age, M, denotes the maximum number of weeks for which a password is valid. A user who attempts to login after his password has expired is forced to supply a new one. The next character, m, denotes the minimum period in weeks that must expire before the password can be changed. The remaining characters define the week (counted from the beginning of 1970) when the password was last changed (a null string is equivalent to zero). M and m have numerical values in the range 0 through 63 that correspond to the 64- character set of "digits" shown above. If m = M = 0 (derived from the string . or ..), the user is forced to change his password next time he logs in (and the "age" disappears from his entry in the password file). If m > M (signified, for example, by the string ./), then only a superuser (not the user) can change the password. Not allowing the user to ever change the password is discouraged, especially on a trusted system.
The pwdb in 6.1 has the fix already.