I believe this step could become idempotent by instead of running the useradd -D -f 30 command within the task, ansible directly manipulates the /etc/default/useradd configuration file through the lineinfile module or something similar. I believe the useradd program will use the values within this configuration according to the man pages.
When running the useradd -D -f 30 command, the /etc/default/useradd file should be updated as follows using the defaults within this role.
# grep INACTIVE /etc/default/useradd
INACTIVE=30
The task might end up looking something like the following.
- name: "SCORED | 5.4.1.4 | PATCH | Ensure inactive password lock is 30 days or less | Set default inactive setting"
lineinfile:
state: present
dest: /etc/default/useradd
regexp: '^INACTIVE'
line: "INACTIVE={{ rhel7cis_inactivelock.lock_days }}"
The following line within rule 5.4.1.4 is not idempotent.
https://github.com/ansible-lockdown/RHEL7-CIS/blob/devel/tasks/section_5/cis_5.4.1.x.yml#L45
I'm testing this by running the following command several times and watching it finish execution with 1 change every time.
I believe this step could become idempotent by instead of running the
useradd -D -f 30
command within the task, ansible directly manipulates the/etc/default/useradd
configuration file through the lineinfile module or something similar. I believe theuseradd
program will use the values within this configuration according to the man pages.When running the
useradd -D -f 30
command, the/etc/default/useradd
file should be updated as follows using the defaults within this role.The task might end up looking something like the following.