This section describes how to use the passwd command from the point of view of an ordinary user and of a system administrator. You can also use Web-based System Manager or SMIT to do these tasks, both of which can be more convenient than running the passwd command as described in this section. This section assumes you have a basic understanding of the NIS+ security system, especially of the role that login passwords play in that system (see the Chapter 7, Security chapter). This section covers:
Logging in to a system is a two-step process:
If your login is successful, your system's message of the day (if any) displays and then your command-line prompt, windowing system, or normal application.
The Login incorrect message indicates that:
If you receive a Your password has expired message, your password has reached its age limit and expired. You must choose a new password at this time. (See Choosing a Password , for criteria that a new password must meet.)
In this case, choosing a new password is a three-step process:
If you receive a Your password will expire in N days message (where N is a number of days), or a Your password will expire within 24 hours message, it means that your password will reach its age limit and expire in that number of days (or hours). It is recommended that you change your password immediately if you receive either message. (See Changing Your Password .)
After entering your login ID and password, you may get a Permission denied message and be returned to the login: prompt. This means that your login attempt has failed because an administrator has either locked your password, or terminated your account, or your password privileges have expired. In these situations a user cannot log in until an administrator unlocks the user password or reactivates the account or privileges.
To maintain security, you should change your password regularly. (See Choosing a Password for password requirements and criteria.) Note that you can also use Web-based System Manager or SMIT to change your password. You may find that more convenient than running the passwd command as described here.
To change your password, use the following steps:
At this point the system checks to make sure that your new password meets system requirements:
See Password Requirements for more information.
Note: When changing root's password, you must always run chkey -p immediately after changing the password. (See Changing Root Keys From Root Master and Changing Root Keys From Another Machine for information on using chkey -p to change root's keys.) Failure to run chkey -p after changing the root password will result in root being unable to properly log in.
Some systems limit either the number of failed attempts you can make in changing your password or the total amount of time you can take to make a successful change. (These limits are implemented to prevent someone else from changing your password by guessing your current password.)
If you fail to successfully log in, someone failes while trying to log in as you, or you fail to change your password within the specified number of tries or time limit, a Too many failures - try later or Too many tries: try again later message displays. You are not allowed to make any more attempts until a certain amount of time has passed. (That amount of time is set by the administrator.)
Many breaches of computer security involve guessing another user's password. While the passwd command enforces some criteria for making sure the password is hard to guess, someone may be able to guess a password correctly just by knowing something about the user. Thus, a good password is one that is easy for you to remember but hard for someone else to guess. A bad password is one that is so hard for you to remember that you have to write it down (which you are not supposed to do), or one that could be guessed by someone who knows about you.
A password should meet the following suggested requirements:
For further information, see the /etc/security/user file description.
Bad choices for passwords include:
Good choices for passwords include:
The passwd command performs various operations regarding passwords. The yppasswd command retains all of its functionality for backward compatibility.
When run in an NIS+ environment, the passwd command is designed to function with or without credentials. Users without credentials are limited to changing their own password. Other password operations can only be performed by users who have credentials (are authenticated) and who have the necessary access rights (are authorized).
In this discussion of authorization and permissions, it is assumed that everyone referred to has the proper credentials.
By default, in a normal NIS+ environment, the owner of the passwd table can change password information at any time and without constraints. In other words, the owner of the passwd table is normally granted full read, modify, create, and destroy authorization (permission) for that table. An owner can also:
Note: Regardless of what permissions they have, everyone in the world and nobody classes must comply with password-aging constraints. In other words, they cannot change a password for themselves or anyone else unless that password exceeded its minimum. Nor can members of the group, world, and nobody classes avoid having to change their own passwords when the age limit has been reached. However, age constraints do not apply to the owner of the passwd table.
To use the passwd command in an NIS+ environment, you must have
the required authorization (access rights) for the operation:
| Access Rights for passwd Command | ||
|---|---|---|
| This Operation | Requires These Rights | To This Object |
| Displaying information | read | passwd table entry |
| Changing information | modify | passwd table entry |
| Adding new information | modify | passwd table |
If you use passwd in an NIS+ environment to change a principal's password, the principal's private (secret) key is updated in the cred table.
If you do not have modify rights to the DES entry, the private key in the cred table will have been formed with a password that is now different from the one stored in the passwd table. In this case, the user must change keys with the chkey command or run keylogin after each login.
The nistbladm command allows you to create, change, and display information about any NIS+ table, including the passwd table.
It is possible to use the nistbladm command to:
New passwords must meet the criteria described in Password Requirements .
To change your password, type
passwd
You are prompted for your old password. Then, you are prompted for the new password, and then for the new password a second time to confirm it.
To change another user's password in the same domain, use:
passwd username
When using the passwd command in an NIS+ environment to change someone else's password you must have modify rights to that user's entry in the passwd table (this usually means that you are a member of the group for the passwd table and the group has modify rights). You do not have to enter either the user's old password or your password. You will be prompted to enter the new password twice to make sure that they match. If they do not match, you will be prompted to enter them again.
When changing the root password, you must always run chkey -p immediately after changing the password with the passwd command. Failure to run chkey -p after changing the root password will result in root being unable to properly log in.
To change a root password, follow these steps:
You must use the -p option.
Password aging is a mechanism you can use to force users to periodically change their passwords.
Password aging encompasses the following tasks:
Users who are already logged in when the various maximums or dates are reached are not affected by the above tasks. They can continue to work as normal.
Password-aging limitations and activities are only activated when a user logs in or performs one of the following operations:
These password-aging parameters are applied on a user-by-user basis. Password-aging requirements can differ for different users. (You can also set general default password aging parameters as described in the /etc/security/user file description.)
You can set a specific date on which a user's password privileges expire. When a user's password privilege expires, that user can no longer have a valid password. In effect, the user is locked out of the system after the given date because after that date, the user can no longer log in.
For example, if you specify an expire date of December 31, 1999, for a user named petew, on January 1, 2000 he will not be able to log in under that user ID regardless of what password he uses. After each login attempt, he will receive a Login incorrect message.
Expiration of a user's password privilege is not the same as password aging.
Password privilege expiration dates only take effect when the user logs in. If a user is already logged in, the expiration date has no ffect until the user logs out or tries to use rlogin or telnet to connect to another machine, at which time the user will not be able to log in again. Thus, to implement password privilege expiration dates, you should require users to log out at the end of each day's work session.
Note: Whenever possible, use Web-based System Manager or SMIT instead of nistbladm to set an expiration date. Both Web-based System Manager and SMIT are easier to use and provides less chance for error.
To set an expiration date with the nistbladm command:
nistbladm -m 'shadow=n:n:n:n:n:n6:n' [name=login],passwd.org_dir
Where:
For example, to specify an expiration date for the user petew of December 31, 2005 you would type:
nistbladm -m 'shadow=n:n:n:n:n:13145:n' [name=petew],passwd.org_dir
Note: All of the fields must be filled in with valid values.
To turn off or deactivate password privilege expiration, you must use the nistbladm command to place a -1 in this field. For example, to turn off privilege expiration for the user huck, you would type:
nistbladm -m 'shadow=n:n:n:n:n:-1:n' [name=huck],passwd.org_dir
Or you can use the nistbladm command to reset the expiration date to a date in the future by entering a new number of days in the n6 field.
You can set a maximum number of days that a user can go without logging in on a given machine. Once that number of days passes without the user logging in, that machine will no longer allow that user to log in. In this situation, the user will receive a Login incorrect message after each login attempt.
This feature is tracked on a machine-by-machine basis, not a network-wide basis. That is, in an NIS+ environment, you specify the number of days a user can go without logging in by placing an entry for that user in the passwd table of the user's home domain. That number applies for that user on all machines on the network. However, the date on which a user last logged in to a given machine is maintained on a machine-by-machine basis in the machine's /var/adm/utmp and/or /var/adm/wtmp (if it exists) file.
For example, suppose you specify a maximum inactivity period of 10 days for the user samh. On January 1, samh logs in to both machine-A and machine-B, and then logs off both machines. Four days later on January 4, samh logs in on machine-B and then logs out. Nine days after that on January 13, samh can still log in to machine-B because only nine days have elapsed since the last time he logged in on that machine. However, he can no longer login to machine-A because thirteen days have passed since his last log in on that machine.
Keep in mind that an inactivity maximum cannot apply to a machine the user has never logged in to. No matter what inactivity maximum has been specified or how long it has been since the user has logged in to some other machine, the user can always log in to a machine that the user has never logged in to previously.
Notes:
- Do not set inactivity maximums unless your users are instructed to log out at the end of each workday. The inactivity feature only relates to logins; it does not check for any other type of system use. If a user logs in and then leaves the system up and running at the end of each day, that user will soon pass the inactivity maximum because there has been no login for many days. When that user finally does reboot or log out, he or she will not be able to log in.
- Whenever possible, use Web-based System Manager or SMIT instead of the nistbladm command to set an inactivity maximum. Web-based System Manager or SMIT are easier to use and provide less chance for error.
To set a login inactivity maximum, you must use the nistbladm command in the format:
nistbladm -m 'shadow=n:n:n:n:n5:n:n' [name=login],passwd.org_dir
Where:
For example, to specify that the user samh must log in at least once every seven days, you would type:
nistbladm -m 'shadow=n:n:n:n:7:n:n' [name=samh],passwd.org_dir
To clear an inactivity maximum and allow a user who has been prevented from logging in to log in again, use nistbladm to set the inactivity value to -1.
You can use the nistbladm command to globally specify password maximum, minimum, warning, inactivity, and expiration values for all principals listed in a given passwd table.
To globally change password aging values for all users listed in a given password table, you use the nistbladm command without an indexed entry between the square brackets. For example, to globally set a minimum of 7 days, a maximum of 30 days, a warning period of 5 days, and no inactivity limit or expiration date, you type:
nistbladm -m 'shadow=n:7:30:5:-1:-1:0' [],passwd.org_dir
You can also use the nistbladm command to turn off password aging for all users in a given password table by globally setting their max value to -1 or 0.
Note: The value you enter in the lastchange field (the first field) will be applied to all the users. In effect, you will be resetting everyone's last change date to that value.
Read the /etc/security/user file description for information on password-related defaults and general criteria that you can specify.
You can specify a number-of-tries limit or an amount-of-time limit (or both) for a user's attempt to change passwords. These limits are specified by adding arguments when starting the rpc.nispasswdd daemon.
Limiting the number of attempts or setting a time frame provides a limited (but not foolproof) defense against unauthorized persons attempting to change a valid password to one that they discover through trial and error.
To set the maximum number of times that a user can try to change a password without succeeding, use rpc.nispasswdd with the -a n option, where n is the number of allowed tries. (You must have root user privileges on the NIS+ master server to run rpc.nispasswdd.)
For example, to limit users to no more than four attempts (the default is 3), type:
rpc.nispasswdd -a 4
In this case, if a user's fourth attempt at logging in is unsuccessful, the message Too many failures - try later displays. No further attempts are permitted for that user ID until a specified period of time has passed.
To set the maximum amount a time that a user can take to successfully change a password, use the -c minutes argument with rpc.nispasswdd, where minutes is the number of minutes a user has to log in. (You must have superuser privileges on the NIS+ master server to run rpc.nispasswdd.)
For example, to specify that users must successfully log in within 2 minutes, type:
rpc.nispasswdd -c 2
In this case, if a user is unable to successfully change a password within 2 minutes, the message is displayed at the end of the two-minute period. No further attempts are permitted for that user ID until a specified period of time has passed.