Password Aging That Reaches The Accounts A Host Already Has

login-defs

EL ships a complete password-aging policy set to 273 years. PASS_MAX_DAYS is 99999 out of the box, PASS_MIN_DAYS is 0, and INACTIVE - which is in a different file - is -1, so a password that does expire never stops working. This role sets all three, and then does the part that is usually left out: it brings the accounts the host already has into the policy, because login.defs only ever describes what useradd will do next time.

No download, and no version to pin. shadow-utils is part of EL 10. What the role owns is two of the distribution's files - it edits the lines it sets and leaves the rest, since there is no login.defs.d to drop into - and the proof that accounts really get what those lines describe.

The two files are read by different tools, which is why both are here. login.defs decides when a password expires; /etc/default/useradd decides how long an expired password still lets you in. A policy that sets only the first expires passwords and locks nobody out.

A policy in login.defs binds accounts created after it lands, and nothing else. Measured: an account made before the policy kept 99999 after the role wrote 365, and only chage moved it. That is why login_defs_apply_to_existing defaults to true and why the live test creates an account BEFORE the role runs, records what it got, and asserts both that the account now carries the policy and that it did not before. Without the second half the test would pass on a host where nothing ever changed.

Nothing validates either file, and a bad value fails OPEN. With PASS_MAX_DAYS notanumber, useradd printed "configuration error - cannot parse PASS_MAX_DAYS value" on stderr, exited 0, and created the account with a maximum of -1. So the live test reads what an account was actually given rather than reading the file back, and it reads /etc/shadow's own fields rather than chage -l: chage reports "Password inactive: never" whenever the password never expires, whatever the inactive field holds, which is how a policy that is half applied reads as a policy that is absent.

root is outside the policy by default. login_defs_existing_min_uid is 1000, so the role never ages root's password. An expired root password on a host with no console is the one mistake here that cannot be undone from the outside. Lower it deliberately if a baseline demands root aging, and make sure there is another way in first.

ENCRYPT_METHOD is here to be kept, not changed. EL 10 already chooses yescrypt ($y$ in /etc/shadow). The role sets it anyway and the test asserts the prefix, so a host that is quietly returned to SHA512 by something else shows up as a failure instead of as nothing at all.

License

Commercial - IaC Bazaar EULA. (c) IaC Bazaar.