chage

How to Manage Password Aging in Solaris, AIX, and Linux

/ Christopher Paquin

LogoIts possible that sometime in your short, meaningless life, you may need to create an account that has a password that is set to never expire. This is somethimes the case with headless accounts and specialty accounts such as the type you might have to setup for monitoring or security scanning. You might also find yourself setting up shared headless accounts that have locked passwords in order to block direct logins. This second scenario can be especially troublesome when this is some sort of application or database user with cron jobs, as even an account without a password and expire and lock. If this occurs all of a users cron jobs will fail. All because the account expired.

So today we are going to configure a user password not to expire.

Lets start with Solaris. First lets unlock the account just in case.

passwd -d username

Now you can turn off password aging for a user with the command below.

passwd -x -1 username

You can then verify your config with the following.

passwd -s dmadmin

The output of the command above should look similar to what I have below. In this example our user id is myuser.

#passwd -s myuser
myuser  PS

Compare what you see above to the output below for our example myuser1, which includes the date that the password was last changed, the minimum number of days between password changes, the maximum number of days required between password changes, and the number of days of warning a user is given before a password expires. Standard system password aging and expiration still applies.

#passwd -s myuser1
myuser1  PS    09/30/13     7    28     7

Now lets move on to Linux. First lets ulock. Then we will configure the password to not expire. Then we can verify our work with the chage -l command.

passwd -u username

chage -m 0 -M 99999 -I -1 -E -1 username

change -l username

So now lets take a visit to AIX land. Remember to not stay long. Again, its always best to make sure that the current password is not locked. Then we configure the password to not expire. Finally we step back and admire our work.

chuser account_locked=false username

chuser maxage=0 username

lsuser -f USERNAME | fgrep expires

Related articles

SuperUser in Linux
How to Unlock an account in Linux
How to Reset a Password on Unix
Much Todo About Linux/RHEL Passwords
Enycrypting Passwords Via SSL for Redhat Kickstart Configuration Files
How to disable an user account in Linux

You are not allowed to access to (crontab) because of pam configuration.

/ Christopher Paquin / 1 Comment

PD Donut Guy with ShadowHey look a real live Linux post.

Sure enough, and right as rain I am back with something that is not about networking (yeah!) and not about Solaris (boo!).

This is a short story about how we had a user who was a member of our database team who was attempting to make modifications to the oracle user’s crontab. They kept running into the error below.

Authentication token expired
You (oracle) are not allowed to access to (crontab) because of pam configuration.

Remembering that the oracle account is a special account without a password, or the ability to login, I figured that it had something to do with the fact the lack or password or something related.

I used the chage command to determine that while the password was not expired, rather that the account was considered inactive. Probably due to the fact that we locked down login permissions for service users on this box, but did not take into account that this user needed to login from time to time to keep the account from becoming inactive.

# chage -l oracle
Last password change                                    : Mar 25, 2013
Password expires                                        : Apr 22, 2013
Password inactive                                       : May 06, 2013
Account expires                                         : never
Minimum number of days between password change          : 7
Maximum number of days between password change          : 28
Number of days of warning before password expires       : 7

Now whats funny about this issue is that its pretty much a time bomb waiting to go off. You lock down logins for service accounts and forget to modify the inactive or expiration dates, and some day in the near future your users cron jobs will stop running, which possibly could cause all hell to break loose depending on whats running out of cron.

The fix is as follows.

# chage -I -1 -m 0 -M 99999 -E -1 oracle

Then use chage again to check out the sexy new settings

# chage -l oracle
Last password change                                    : Mar 25, 2013
Password expires                                        : never
Password inactive                                       : never
Account expires                                         : never
Minimum number of days between password change          : 0
Maximum number of days between password change          : 99999
Number of days of warning before password expires       : 7

Related articles

HomeLab: Simple SSH Setup on a Cisco Router
HomeLab: Cisco 2621 Router Password Recovery/Factory Reset
chkcrontab 1.6
How to Use Cron to Automate Tasks on a VPS

RHEL – Managing Passwords with Chage

/ Christopher Paquin / Leave a comment

Large_SkeletonKeyPTo understand the chage command  if might be best to make sure that you understand the /etc/shadow file, so lets look at a line from mine. Note that “:” is the field separator.

chris:$6$MZsU1MdDNVs50KaP$.sPNd90oOieOHAMwWt5rVB1:15188:0:99999:7:::

In the shadow file the fields are as follows:

  1. Username
  2. Password Hash
  3. Date of Last Password Change in days since the dawn of Unix Time
  4. Minimum Password Age
  5. Maximum Password Age
  6. Password Warning Period
  7. Password Inactive Period
  8. Account Expiration

The basic options of the chage command are as follows

  • -M Max Days
  • -m Min Days
  • -I inactive
  • -E Expiry Date
  • -D 0 Force Password Change

So first lets take a look at the current settings for user “chris”. You will see that the entries below match the options listed above.

# chage -l chris

Last password change                                    : Aug 02, 2011
Password expires                                        : never
Password inactive                                       : never
Account expires                                         : never
Minimum number of days between password change          : 0
Maximum number of days between password change          : 99999
Number of days of warning before password expires       : 7

So lets say that we want to force user chris to update his password on next login

#chage -d 0 chris

and then set a minimum number of days of 10 between password changes

#chage -m 10 chris

or set an expiration date of 10/10/2020

#chage -E 10/10/2020 chris

You get the idea…

Anyway the chage command can be run interactively as well if you do not pass any options to the command other than the username.

Additional Resources:

Managing Password Aging on AIX, Solaris, Linux

http://www.thegeekstuff.com/2009/04/chage-linux-password-expiration-and-aging/