Image Credit: Ohio State University

Yesterday in my post on Solaris 10 Password Policy Enforcement, I outlined the steps necessary to implement the password requirements that have been decided upon in my system environment.  This post will outline the same process on the RHEL5 systems that I admin.  While the policy requirements are the same, the implementation is vastly different.

Desired Policy

To re-cap, here is the policy that is to be applied to normal users:

• at least 8 characters in length
• no more than 20 characters in length
• contain at least on letter
• contain at least one number
• forced to change at least every 180 days
• 15 minute lockout after 5 unsuccessful attempts

Implementation Differences with Solaris 10

While there were a couple of pieces of the desired password policy that I was unable to implement on Solaris 10, the ease of which the others were configured wins the game hands down.  The PAM module setup on Solaris makes it dead simple to update the policy.  All you have to do is to change the various tunable settings.  And they are all listed in fairly understandable verbiage, no complex or arcane settings.

On the RHEL5 systems I had to delve into the vagaries of PAM module attributes and ordering.  As always, it is important to make backups of any files to protect yourself and allow for disaster recovery. To implement the requirements, I had to edit two files on the system:

1. /etc/login.defs
2. /etc/pam.d/system-auth

Implementation Process

It is important during this process to recognize that if you set the PAM requirements incorrectly you can get burned to the point that the root user will be unable to login, forcing you to boot into single-user mode to recover or to boot the system from a live cd and revert the authentication files.

Setting the password expiration requirement and length setting

Before we get into this please note the warning notice from the login.defs file manpage on a RHEL5 system

Much of the functionality that used to be provided by the shadow password suite is now handled by PAM. Thus, /etc/login.defs is no longer used by programs such as: login(1), passwd(1), su(1). Pleaserefer to the corresponding PAM configuration files instead.

It is still important to configure the password length in the login.defs file so that we can account for legacy codebases.

1. Open /etc/login.defs in your favorite editor
2. Set the attribute of PASS_MAX_DAYS to be 180
3. Set the attribute of PAS_MIN_LEN to be 9

Setting the password complexity requirements

Now here is where the going gets real interesting.  Before we look at /etc/pam.d/system-auth a strong caution

Backup up the file before you alter it and open a backup terminal session as the root user before continuing.  If you put the wrong attributes in place or put the PAM directives in the wrong order you will lock yourself, root user and all, out of the system.  At that point you have two options: single user mode recovery from the console or use a live cd to boot the machine and revert to the backup after mounting the filesystem.  Oh, and it is wise to give yourself a delay with either GRUB or LILO because without the delay you won’t be able to change the boot option to allow the single user mode recovery option.

So, the file involved in this process is /etc/pam.d/system-auth and before I go into some of the nitty gritty, here’s the configuration I ended up using:

#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth        required      pam_env.so
auth        required      pam_tally2.so deny=6 unlock_time=900
auth        sufficient    pam_unix.so nullok try_first_pass nodelay
auth        requisite     pam_succeed_if.so uid >= 500 quiet
auth        required      pam_deny.so
 
account     required      pam_unix.so
account     sufficient    pam_succeed_if.so uid < 500 quiet
account     required      pam_permit.so
account     required      pam_tally2.so per_user
 
password    required      pam_passwdqc.so min=disabled,disabled,12,9,9 max=20 similar=deny enforce=users retry=3
password    sufficient    pam_unix.so md5 shadow nullok try_first_pass use_authtok
password    required      pam_deny.so
 
session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so

The retries requirement is implemented using the following line

auth        required      pam_tally2.so deny=6 unlock_time=900

The complexity and length requirements are implements using the following line

password    required      pam_passwdqc.so min=disabled,disabled,12,9,9 max=20 similar=deny enforce=users retry=3

The following line is set to ensure that the retries count is maintained even if the counter for the pam_tally2 module is corrupted

account     required      pam_tally2.so per_user

References

Rather than go into the details of each individual attribute and how they interact, here are the resources used to develop this ruleset.  They contain an large amount of valuable information.

1. http://wiki.centos.org/HowTos/OS_Protection#head-c6bf533e4f6de1ff3e13d556053fc40bc121e5cc
2. http://www.openwall.com/passwdqc/README.shtml
3. http://www.puschitz.com/SecuringLinux.shtml#LockingUserAccountsAfterTooManyLoginFailures
4. http://www.linux.com/archive/feature/113807