"Manage Password Aging parameters for both the existing and future Systems Users"

Steve ESSO



6,163 latest version

4.6 quality score

Version information

  • 0.2.0 (latest)
  • 0.1.0
released Mar 28th 2016
This version is compatible with:
  • RedHat

Start using this module


stivesso/password_aging — version 0.2.0 Mar 28th 2016


Table of Contents

  1. Overview
  2. Module Description - What the module does and why it is useful
  3. Setup - The basics of getting started with password_aging
  4. Usage - Configuration options and additional functionality
  5. Reference - An under-the-hood peek at what the module is doing and how
  6. Limitations - OS compatibility, etc.
  7. Development - Guide for contributing to the module
  8. TODO
  9. Contributors


The main aim of this module is to manage Password Aging parameters for both existing and future users. The main parameters that are currently managed under this module are:

pass_max_days : Maximum number of days a password may be used (default: 99999 days)
pass_min_days : Minimum number of days allowed between password changes (default: 0 day)
pass_min_len : Minimum Lenght of a password (default: 5 character)
pass_warn_age : Password Warning Period before Expritation (default: 7 days)
params_file : the parameters file (default on Linux : /etc/login.defs)
manage_existing_user : Whether or not there is a list of Existing Users which needs these settings (especially max/min days)
** users_to_manage : If there are some existing Users to manage, Lists those users in an array

Module Description

The module mainly configures systems files that are needed for password aging. It also relies on Puppet User resource to affect existing Users.


From Puppet Forge,

puppet module install stivesso-password_aging

From Github,

git clone

What password_aging affects

  • /etc/login.defs
  • /etc/shadow

Setup Requirements

Currently require:

  • puppetlabs/stdlib
  • pluginsync = true (on Puppet Configuration)


To accept default class parameters(default values for password aging are specified above, added to that, we have manage_existing_user which by default is set to false):

include password_aging

It is to note that PASS_MAX_DAYS, PASS_MIN_DAYS and PASS_WARN_AGE as defined above are only used at the time of account creation. Changes to these settings won't affect existing accounts. So If some Existing Accounts need to be aligned to a new defined policy, then there is a need to set manage_existing_user to true and define an array with these existing Users (as seen in the next example below)

With more details (while modifying the settings for existing oracle, root and user2):

class  { password_aging:
   pass_max_days         => "90", 
   pass_min_days         => "4", 
   pass_min_len          => "8", 
   pass_warn_age         => "7", 
   manage_existing_user  => true,
   users_to_manage       => ["oracle","root","user2"],

The module also supports (and encourages) configuration through hiera. Below is an example of such configuration:

password_aging::pass_max_days: "180"
password_aging::pass_min_days: "28"
password_aging::pass_min_len: "8"
password_aging::pass_warn_age: "7"
password_aging::manage_existing_user: true
  - "oracle"
  - "root"


The main used class is password_aging with the parameters described above,


Have been tested on RHEL-Like Distribution only (RHEL,CENTOS,FEDORA,ORACLE LINUX)


I happily accept bug reports and pull requests via github,

Procedure for the Pull Request (PR):

  • Fork password_aging Repository
  • Create a topic branch against the dev branch:
    git checkout develop; git checkout -b my_branch
  • Push to your branch git push origin my_branch
  • Create a Pull Request from your branch against the develop branch


  • Add Others Unix (Solaris,AIX,HP-UX) Support