When connecting to the target server with an AD account the rule 5.3.4 gets incorrectly triggered and the playbook fails.
To clarify, this occurs in the initial checks before the main patching happens. The task is named TASK [rhel9-cis : Check password set for antest | Assert password set and not locked] in tasks/main.yml.
Cause
This is caused by the way the rule expects there to be an entry in the /etc/shadow file. This is only the case for local accounts.
As the grep cannot find the user it returns nothing to awk which results in a zero-length password
name: "Check password set for {{ ansible_env.SUDO_USER }} | Assert password set and not locked" ansible.builtin.assert: that: rhel9cis_ansible_user_password_set.stdout | length != 0 and rhel9cis_ansible_user_password_set.stdout != "!!"
Additionally the comments suggest that the intention was to detect locked accounts. The rule currently does not do this. Note that the double exclam "!!" denotes that the password has not been set yet as in the case of a new user. A locked account will get a single exclam "!" prepended to the hashed password. This would actually pass the check as written.
Expected behaviour
For an AD account the password length and lockout checking will be skipped. I suggest it is beyond the scope of the playbook to interrogate the AD rules in play.
For a local account if the password has not been set, shown by "!!" in /etc/shadow, then it fails with an appropriate message.
For a local account if the account has been locked, shown by the password hash beginning with a single exclam "!" in /etc/shadow, then it fails with an appropriate message.
Actual behaviour
For an AD account the playbook fails with the bogus error message regarding password length.
For a local account that has previously had a password but which has since been locked, then it incorrectly passes the check and the playbook proceeds.
Controls affected
This prevents the playbook from being run using an AD account.
Environment
Branch: devel
Ansible: core 2.15.8
Target host python: 3.9.18
Ansible Server Python: 3.9.17
Additional target host OS: Alma 9
Additional notes
Nothing to add.
Possible solution
I have a proposed solution for which I will be creating a Pull Request.
Issue
When connecting to the target server with an AD account the rule 5.3.4 gets incorrectly triggered and the playbook fails.
To clarify, this occurs in the initial checks before the main patching happens. The task is named TASK [rhel9-cis : Check password set for antest | Assert password set and not locked] in tasks/main.yml.
Cause
This is caused by the way the rule expects there to be an entry in the /etc/shadow file. This is only the case for local accounts.
Code being run by the rule.
As the grep cannot find the user it returns nothing to awk which results in a zero-length password
Additionally the comments suggest that the intention was to detect locked accounts. The rule currently does not do this. Note that the double exclam "!!" denotes that the password has not been set yet as in the case of a new user. A locked account will get a single exclam "!" prepended to the hashed password. This would actually pass the check as written.
Expected behaviour
Actual behaviour
Controls affected
This prevents the playbook from being run using an AD account.
Environment
Additional notes
Nothing to add.
Possible solution
I have a proposed solution for which I will be creating a Pull Request.