This bug has been migrated to another issue tracking site. It has been closed here and may no longer be being monitored.

If you would like to get updates for this issue, or to participate in it, you may do so at Red Hat Issue Tracker .
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 2038620 - [RFE] [RHEL7/8] Create and provide RHEL System Role for managing a Password Policy
Summary: [RFE] [RHEL7/8] Create and provide RHEL System Role for managing a Password P...
Keywords:
Status: CLOSED MIGRATED
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: pam
Version: 8.5
Hardware: x86_64
OS: Linux
unspecified
low
Target Milestone: rc
: ---
Assignee: Iker Pedrosa
QA Contact: sssd-qe
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-01-09 01:39 UTC by pdoiphod
Modified: 2024-01-17 04:26 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2023-09-18 23:49:52 UTC
Type: Story
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker   RHEL-4987 0 None Migrated None 2023-09-18 23:49:48 UTC
Red Hat Issue Tracker RHELPLAN-107203 0 None None None 2022-01-09 01:43:28 UTC
Red Hat Issue Tracker SSSD-4256 0 None None None 2022-01-13 15:27:28 UTC
Red Hat Issue Tracker SSSD-7083 0 None None None 2024-01-17 04:26:53 UTC

Description pdoiphod 2022-01-09 01:39:46 UTC
Description of problem:

Every organisation uses (or at least should use) some kind of password policy today. For different RHEL releases are different ways to create one. Documented are these i.e. in the following KBs:

 * [Set a password policy in Red Hat Enterprise Linux 7](https://access.redhat.com/solutions/2808101)
 * [Set Password Policy/Complexity in Red Hat Enterprise Linux 8](https://access.redhat.com/solutions/5027331)
 * [How to lock out a user to login a system after a set number of failed attempts in Red Hat Enterprise Linux using pam_tally/pam_tally2](https://access.redhat.com/solutions/4303)
 

IMHO this is perfect job to get done by a RHEL system role that covers the following ToDos:

1. Keep history of used passwords (the number of previous passwords which cannot be reused).
2. Enforce root for password complexity.
3. Password size (Minimum acceptable size for the new password).
4. Set limit to number of digits in password.
5. Set limit to number of Upper Case characters in password.
6. Set limit to number of Lower Case characters in password.
7. Set limit to number of Other characters in password.
8. Set minimum number of required classes in new password (digits, uppercase, lowercase, others).
9. Set maximum number of allowed consecutive same characters in the new password.
10. A maximum number of allowed consecutive characters of the same class in the new password.
11. A maximum number of characters that is allowed to use in new passwords(compared to old password.

I would appreciate when you process this RFE and I found some new Ansible role for this in an upcoming release of RHEL System Roles.


Version-Release number of selected component (if applicable):

RHEL7, RHEL8


How reproducible: 100%


Actual results:

There are separate ways for RHEL 7 and RHEL 8 servers to configure different password policies.


Expected results:

Ansible system role for creating password policies which can be used for any RHEL veresion. So that different methods of configurin password policy need not to be used.

Comment 6 Joerg K 2022-01-11 08:12:17 UTC
Of course this RFE doesn't apply to RHEL 7 and 8 only, but to the upcoming RHEL 9 as well.
Customers would get the max benefit when every supported RHEL major release can be configured using the suggested in this RFE.

Comment 7 Christian Horn 2022-01-12 08:24:48 UTC
That's a good idea.
Just to give ideas what could be a good start: if someone sees this
useful for a specific release, then he/she could implement Ansible code
in a role for just that specific release - having that code there for the
first release makes further implementations easier, and already that code
could get considered to get included in RHEL.

Comment 8 Rich Megginson 2022-01-12 11:39:33 UTC
Is this for cases where you cannot use Red Hat Identity Management aka IdM aka freeipa?  There are ansible roles for freeipa, and I'm pretty sure they allow you to manage the password settings.  @twoerner please confirm.

Comment 9 Joerg K 2022-01-12 12:09:53 UTC
(In reply to Rich Megginson from comment #8)
> Is this for cases where you cannot use Red Hat Identity Management aka IdM
> aka freeipa?  There are ansible roles for freeipa, and I'm pretty sure they
> allow you to manage the password settings.

Yes, kind of. We don't use IdM, freeipa, etc. We use local users and groups that are created using Ansible. So we would like to use Ansible for the configuration of a password policy as well.

Would it be possible to use ansible roles from the freeip project without the need to implement an IdM server in our environment?

Comment 10 Rich Megginson 2022-01-12 12:57:31 UTC
(In reply to Joerg K from comment #9)
> (In reply to Rich Megginson from comment #8)
> > Is this for cases where you cannot use Red Hat Identity Management aka IdM
> > aka freeipa?  There are ansible roles for freeipa, and I'm pretty sure they
> > allow you to manage the password settings.
> 
> Yes, kind of. We don't use IdM, freeipa, etc. We use local users and groups
> that are created using Ansible. So we would like to use Ansible for the
> configuration of a password policy as well.
> 
> Would it be possible to use ansible roles from the freeip project without
> the need to implement an IdM server in our environment?

I don't think so, but perhaps Thomas would know for sure.  I think for this use case you really need a way to manage the PAM config files/services directly.

Comment 11 Joerg K 2022-02-17 10:58:05 UTC
Hi there,

So I cloned the template at https://github.com/linux-system-roles/template and started working on my very first try to contribute to the Linux System Roles project.

You'll find my first minimal version which is not fully functional, not production ready and for sure full of bugs and bad practises yet at: https://github.com/Tronde/pam_pwd.

Since this is my very first attempt to contribute to the Linux System Role project I would like to ask for some early guidance and mentoring. Please let me know if you see any issues or problems in style of coding etc.

Your feedback is welcome and appreciated to help me to improve my skill.

I still have to deal with some issues implementing the steps for a password policy described in the Red Hat KB [Set Password Policy/Complexity in Red Hat Enterprise Linux 8](https://access.redhat.com/solutions/5027331). And I'm going to check how things work in RHEL 9 Beta. So I may have to move some tasks to release specific playbooks.

But I'm very interested in getting early feedback from you folks so I won't run in the wrong direction for a long time.

Comment 12 Iker Pedrosa 2022-02-17 16:09:09 UTC
I can't give you great feedback from the System Roles perspective because I'm not an expert in that area, but I have some concerns about the changes from the PAM perspective.

The equivalent of authselect in RHEL7 is authconfig, why don't you use it?
The default value of pam_pwd_history in pam_pwhistory is 10. Can you set the same value?
I don't think you should provide templates for faillock.conf, password-auth and system-auth as copying these files could override any settings the system administrator has previously written to them. Also, the PAM stack files contain additional changes that will not be used. I think you should limit yourself to modifying only the lines containing pam_pwhistory.

Comment 13 Joerg K 2022-02-17 19:06:55 UTC
(In reply to Iker Pedrosa from comment #12)
> I can't give you great feedback from the System Roles perspective because
> I'm not an expert in that area, but I have some concerns about the changes
> from the PAM perspective.

Thank you very much for your feedback. I appreciate it.

> The equivalent of authselect in RHEL7 is authconfig, why don't you use it?

I try to implement the steps mentioned in the solution article [Set a password policy in Red Hat Enterprise Linux 7](https://access.redhat.com/solutions/2808101). Requirement 1 says to insert some text in `/etc/pam.d/system-auth` and `/etc/pam.d/password-auth`. But on RHEL 7 these files are symlinks to  `/etc/pam.d/{system,password}auth-ac` which are managed by `authconfig` and manually changes could get overwritten. So I raised support case 03109116 to ask for advice how to keep a history of passwords used for RHEL 7 in an `authconfig` compatible way. And Support told me: "..you are using rhel7.9 server and on rhel7 its fine to manually edit pam files. 'authconfig' is an additional utility.

Talking about symbolic links, those are the symbolic links but that has nothing to do with updating files manually. 
The symbolic links will get updated automatically.

So you will need to update the /etc/pam.d/system-auth and /etc/pam.d/password-auth files manually."

This answer and that I didn't find a way to use authconfig keep a password history lead to my solution so far.

> The default value of pam_pwd_history in pam_pwhistory is 10. Can you set the
> same value?

Yes, I will do that. I set it to "5" because the solution article used this value, too. But I'll change the default value in the role.

> I don't think you should provide templates for faillock.conf, password-auth
> and system-auth as copying these files could override any settings the
> system administrator has previously written to them. Also, the PAM stack
> files contain additional changes that will not be used. I think you should
> limit yourself to modifying only the lines containing pam_pwhistory.

You're probably right here. I'll think about how to change these values instead of using templates.

Comment 14 Rich Megginson 2022-02-18 01:42:25 UTC
(In reply to Joerg K from comment #13)
> (In reply to Iker Pedrosa from comment #12)
> > I can't give you great feedback from the System Roles perspective because
> > I'm not an expert in that area, but I have some concerns about the changes
> > from the PAM perspective.
> 
> Thank you very much for your feedback. I appreciate it.
> 
> > The equivalent of authselect in RHEL7 is authconfig, why don't you use it?
> 
> I try to implement the steps mentioned in the solution article [Set a
> password policy in Red Hat Enterprise Linux
> 7](https://access.redhat.com/solutions/2808101). Requirement 1 says to
> insert some text in `/etc/pam.d/system-auth` and `/etc/pam.d/password-auth`.
> But on RHEL 7 these files are symlinks to 
> `/etc/pam.d/{system,password}auth-ac` which are managed by `authconfig` and
> manually changes could get overwritten. So I raised support case 03109116 to
> ask for advice how to keep a history of passwords used for RHEL 7 in an
> `authconfig` compatible way. And Support told me: "..you are using rhel7.9
> server and on rhel7 its fine to manually edit pam files. 'authconfig' is an
> additional utility.
> 
> Talking about symbolic links, those are the symbolic links but that has
> nothing to do with updating files manually. 
> The symbolic links will get updated automatically.
> 
> So you will need to update the /etc/pam.d/system-auth and
> /etc/pam.d/password-auth files manually."
> 
> This answer and that I didn't find a way to use authconfig keep a password
> history lead to my solution so far.
> 
> > The default value of pam_pwd_history in pam_pwhistory is 10. Can you set the
> > same value?
> 
> Yes, I will do that. I set it to "5" because the solution article used this
> value, too. But I'll change the default value in the role.
> 
> > I don't think you should provide templates for faillock.conf, password-auth
> > and system-auth as copying these files could override any settings the
> > system administrator has previously written to them. Also, the PAM stack
> > files contain additional changes that will not be used. I think you should
> > limit yourself to modifying only the lines containing pam_pwhistory.
> 
> You're probably right here. I'll think about how to change these values
> instead of using templates.

I suggest using lineinfile - which you are already using in your proposed role.  (I don't normally recommend using lineinfile https://github.com/redhat-cop/automation-good-practices/blob/main/coding_style/README.adoc#ansible-guidelines "Avoid the use of lineinfile wherever that might be feasible.", but I think this is one of those cases where there are no good alternatives).

Comment 15 Joerg K 2022-03-11 13:09:54 UTC
Hello,
I would like to ask you folks for you opinion on the following matter.

To create the system role I tried to simply implement the KBs:

 * [Set a password policy in Red Hat Enterprise Linux 7](https://access.redhat.com/solutions/2808101)
 * [Set Password Policy/Complexity in Red Hat Enterprise Linux 8](https://access.redhat.com/solutions/5027331)

In doing so I have a lot of conditionals and tasks using the command module, because I have to deal with authselect(8) in RHEL 8 while I would edit the files /etc/pam.d/{password,system}-auth and /etc/security/pwquality.conf directly in RHEL 7. I aussumed that authselect(8) is the prefered way to go in RHEL 8, but I'd might mistaken there. The manpage for authselect(8) says that it is an OPT-IN tool and not used by default. I can confirm this. An `authselect current` on a fresh RHEL 8 box shows no configuration in use.

Now, my idea is to drop the authselect tasks from my role and just edit the files /etc/pam.d/{password,system}-auth and /etc/security/pwquality.conf like I'm going to do for RHEL 7. I guess there is a pretty good chance I would get a nice system role usable for RHEL 7, 8 and maybe 9 as well. But it might cause trouble when applied to hosts already using authselect. IMHO it would be OK to describe that you cannot use this role together with authselect in the role's description. What do you think about it?

Best regards,
Joerg

Comment 16 Iker Pedrosa 2022-03-11 14:28:39 UTC
IMHO, it should be the other way round, assuming that authselect is the way to go. RHEL (and Fedora) are both going in a direction where authselect is supposed to handle the PAM stack. As an example, recently there was a Fedora system wide change to move all the PAM stack files owned by the PAM package to authselect. This way, we can have a "clean" role at the expense of not including RHEL7, but including RHEL8 and 9 and any future version. I wonder, is it too difficult to handle it that way?

Comment 17 Rich Megginson 2022-03-11 14:35:25 UTC
(In reply to Iker Pedrosa from comment #16)
> IMHO, it should be the other way round, assuming that authselect is the way
> to go. RHEL (and Fedora) are both going in a direction where authselect is
> supposed to handle the PAM stack. As an example, recently there was a Fedora
> system wide change to move all the PAM stack files owned by the PAM package
> to authselect. This way, we can have a "clean" role at the expense of not
> including RHEL7, but including RHEL8 and 9 and any future version. I wonder,
> is it too difficult to handle it that way?

Do you mean - is it too difficult to have conditional logic for the platform version?  The answer is no - there are many system roles that have such logic - and even the network role has conditionals depending on the version of network manager used (in addition to os platform and version) - there are various ways to do this, depending on what exactly we need to do - see https://github.com/redhat-cop/automation-good-practices/tree/main/roles#supporting-multiple-distributions-and-versions

Comment 18 Joerg K 2022-03-11 16:30:02 UTC
(In reply to Iker Pedrosa from comment #16)
> IMHO, it should be the other way round, assuming that authselect is the way
> to go. RHEL (and Fedora) are both going in a direction where authselect is
> supposed to handle the PAM stack. As an example, recently there was a Fedora
> system wide change to move all the PAM stack files owned by the PAM package
> to authselect. This way, we can have a "clean" role at the expense of not
> including RHEL7, but including RHEL8 and 9 and any future version. I wonder,
> is it too difficult to handle it that way?

Well, I did not know that Fedora and RHEL are both going in the direction to use authselect. In that case I'm glad I asked. It won't be a problem to include the logic needed, as @rmeggins already pointed out.

Please bear with me, even if I ask questions where the answer seems obvious. I don't have any experience yet and try to learn how to do it. I got a lot of tips from Rich already where I'm trying to get through. I hope to put some of the suggestions into code, soon.

Thanks for your feedback.

Comment 19 Iker Pedrosa 2022-03-21 13:05:18 UTC
Joerg I think that you should be aware of https://bugzilla.redhat.com/show_bug.cgi?id=2063379, as it could facilitate your work for this task.

Comment 20 Joerg K 2022-03-21 13:43:40 UTC
(In reply to Iker Pedrosa from comment #19)
> Joerg I think that you should be aware of
> https://bugzilla.redhat.com/show_bug.cgi?id=2063379, as it could facilitate
> your work for this task.

Hi Iker,  
Thanks for letting me know. I added myself to the CC list. I would definetily facilitate my work as I won't have to use the lineinfile module anymore. That said I'm currently using this module and it seems to work. But I would prefer to be able to abstain from using regexp and editing files directly.

Comment 21 Joerg K 2022-04-06 11:47:19 UTC
Current status and call for help
================================

The role is still in an early state. Currently all unit tests passed. In the next step I would like to run some integration tests but still have some trouble to get them up and running (https://ask.fedoraproject.org/t/modulenotfounderror-no-module-named-yaml/21156). So I would like to ask for your help to:

 * Test my role against different Releases, e.g. RHEL 7, RHEL 8, RHEL 9 beta, CentOS Stream, Fedora 35, etc. and give me some feedback wether it works or not. In case not I would appreciate if you raise an issue on GitHub.
 * Take a close look to the [README.md](https://github.com/Tronde/pam_pwd/blob/master/README.md) and tell me if anything is missing or not clear how to use this role. Please raise GitHub issues for this as well.

Project-URL: https://github.com/Tronde/pam_pwd

I know it's a lot to ask as we all have busy days and a lot on our plate. Any help is much appreciated. Thanks in advance for your support.

Comment 22 Rich Megginson 2022-04-06 13:04:08 UTC
(In reply to Joerg K from comment #21)
> Current status and call for help
> ================================
> 
> The role is still in an early state. Currently all unit tests passed. In the
> next step I would like to run some integration tests but still have some
> trouble to get them up and running
> (https://ask.fedoraproject.org/t/modulenotfounderror-no-module-named-yaml/
> 21156).

I have replied on that thread.

> So I would like to ask for your help to:
> 
>  * Test my role against different Releases, e.g. RHEL 7, RHEL 8, RHEL 9
> beta, CentOS Stream, Fedora 35, etc. and give me some feedback wether it
> works or not. In case not I would appreciate if you raise an issue on GitHub.
>  * Take a close look to the
> [README.md](https://github.com/Tronde/pam_pwd/blob/master/README.md) and
> tell me if anything is missing or not clear how to use this role. Please
> raise GitHub issues for this as well.
> 
> Project-URL: https://github.com/Tronde/pam_pwd
> 
> I know it's a lot to ask as we all have busy days and a lot on our plate.
> Any help is much appreciated. Thanks in advance for your support.

Comment 23 Brian Smith 2022-04-14 14:47:40 UTC
(In reply to Joerg K from comment #21)
> Current status and call for help
> ================================
> 
> The role is still in an early state. Currently all unit tests passed. In the
> next step I would like to run some integration tests but still have some
> trouble to get them up and running
> (https://ask.fedoraproject.org/t/modulenotfounderror-no-module-named-yaml/
> 21156). So I would like to ask for your help to:
> 
>  * Test my role against different Releases, e.g. RHEL 7, RHEL 8, RHEL 9
> beta, CentOS Stream, Fedora 35, etc. and give me some feedback wether it
> works or not. In case not I would appreciate if you raise an issue on GitHub.
>  * Take a close look to the
> [README.md](https://github.com/Tronde/pam_pwd/blob/master/README.md) and
> tell me if anything is missing or not clear how to use this role. Please
> raise GitHub issues for this as well.

Hi Joerg,
A couple of ideas for the README.md:  include information on which OS's / versions work with the role, information on if role variables are required and/or have default values, and perhaps add a couple of additional examples.

Comment 24 Joerg K 2022-04-19 08:42:19 UTC
(In reply to Brian Smith from comment #23)
> (In reply to Joerg K from comment #21)
> Hi Joerg,
> A couple of ideas for the README.md:  include information on which OS's /
> versions work with the role, information on if role variables are required
> and/or have default values, and perhaps add a couple of additional examples.

Thanks for your feedback Brian.
I've put some more info into the README.md and add one more example in the role's example directory.

Comment 25 Rich Megginson 2022-07-20 16:33:40 UTC
I have imported Joerg's pam_pwd role into linux system roles - https://github.com/linux-system-roles/pam_pwd - and also to Galaxy - https://galaxy.ansible.com/linux-system-roles/pam_pwd - please take a look

Comment 26 Iker Pedrosa 2022-07-21 08:47:48 UTC
I haven't been able to test it but the documentation looks good to me.

One minor issues that I've found is that the linux system roles define that the fedora versions supported are 35+ but in Galaxy, there's an "OS Platforms" table that states fedora 16+. Is this table something generic?

Comment 27 Rich Megginson 2022-07-21 15:51:18 UTC
(In reply to Iker Pedrosa from comment #26)
> I haven't been able to test it but the documentation looks good to me.
> 
> One minor issues that I've found is that the linux system roles define that
> the fedora versions supported are 35+ but in Galaxy, there's an "OS
> Platforms" table that states fedora 16+. Is this table something generic?

In the role metadata we define Fedora support as all versions - https://github.com/linux-system-roles/pam_pwd/blob/main/meta/main.yml#L49
This means "all supported versions of Fedora" which is whatever is current (e.g. 35 and 36 right now)
I would say that it is probably a bug in Galaxy that it doesn't make sense to list role support for platforms that are not supported, except possibly for historical purposes.  OTOH, it may be that Galaxy doesn't like the fact that we use "all" for Fedora version support and perhaps they would appreciate it if we would explicitly list the versions of Fedora - but then that means we would need to update the meta/main.yml every 6 months or so and publish a new role even when nothing has changed . . .

Comment 28 Iker Pedrosa 2022-08-30 14:39:23 UTC
Since the role was already provided I guess we could close this bugzilla. Right?

Comment 29 Rich Megginson 2022-08-30 14:51:42 UTC
(In reply to Iker Pedrosa from comment #28)
> Since the role was already provided I guess we could close this bugzilla.
> Right?

Well, adding pam_pwd to upstream linux-system-roles is the first step in a long, long process of productization - that is - if a Red Hat RHEL customer sees this BZ as CLOSED, they are going to assume pam_pwd is in the rhel-system-roles RPM, and that won't happen for a while

Comment 30 Thomas Woerner 2022-10-05 09:16:20 UTC
(In reply to Rich Megginson from comment #8)
> Is this for cases where you cannot use Red Hat Identity Management aka IdM
> aka freeipa?  There are ansible roles for freeipa, and I'm pretty sure they
> allow you to manage the password settings.  @twoerner please
> confirm.

Yes, there are is a plugin in ansible-freeipa to manage password policy with Red Hat Identity Management.

Comment 32 RHEL Program Management 2023-09-18 23:49:14 UTC
Issue migration from Bugzilla to Jira is in process at this time. This will be the last message in Jira copied from the Bugzilla bug.

Comment 33 RHEL Program Management 2023-09-18 23:49:52 UTC
This BZ has been automatically migrated to the issues.redhat.com Red Hat Issue Tracker. All future work related to this report will be managed there.

Due to differences in account names between systems, some fields were not replicated.  Be sure to add yourself to Jira issue's "Watchers" field to continue receiving updates and add others to the "Need Info From" field to continue requesting information.

To find the migrated issue, look in the "Links" section for a direct link to the new issue location. The issue key will have an icon of 2 footprints next to it, and begin with "RHEL-" followed by an integer.  You can also find this issue by visiting https://issues.redhat.com/issues/?jql= and searching the "Bugzilla Bug" field for this BZ's number, e.g. a search like:

"Bugzilla Bug" = 1234567

In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues. You can also visit https://access.redhat.com/articles/7032570 for general account information.

Comment 34 Red Hat Bugzilla 2024-01-17 04:25:14 UTC
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days


Note You need to log in before you can comment on or make changes to this bug.