Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
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.
DescriptionJan Pazdziora (Red Hat)
2020-03-20 16:05:51 UTC
Description of problem:
The sssd.conf(5) says:
pwfield (string)
The value that NSS operations that return users or groups will return for the “password” field.
This option can also be set per-domain.
Default: “*” (remote domains) or “x” (the files domain)
However, for users returned via proxy files id_provider, * is returned. That in turn breaks PAM authentication.
Version-Release number of selected component (if applicable):
sssd-2.2.3-20.el8.x86_64
How reproducible:
Deterministic.
Steps to Reproduce:
1. Have system without SSSD configured and started.
2. Set password for user test: passwd test
3. Test that PAM authentication or user test works:
echo $THE_PASSWORD | pamtester sssd-shadowutils test authenticate
If you don't like to use pamtester from EPEL, just use ssh test@localhost.
4. getent passwd test, check that the output is
test:x:1000:1000::/home/test:/bin/bash
5. Configure SSSD, create /etc/sssd/sssd.conf with:
[sssd]
domains = PROXY_PROXY
services = nss
[domain/PROXY_PROXY]
id_provider = proxy
proxy_lib_name = files
proxy_pam_target = sssd-shadowutils
6. chmod 600 /etc/sssd/sssd.conf or SSSD refuses to start.
7. systemctl restart sssd
8. getent passwd test
9. echo $THE_PASSWORD | pamtester sssd-shadowutils test authenticate
Actual results:
test:*:1000:1000::/home/test:/bin/bash
Password: pamtester: Authentication failure
Expected results:
test:x:1000:1000::/home/test:/bin/bash
Password: pamtester: successfully authenticated
Additional info:
It is possible to force the expected behaviour by adding line
pwfield = x
to the [domain/...] section. But SSSD should obey what it says in the man page, and it should not as easily break PAM authentication of unrelated services.
I think we can do the following:
1. (required bugfix) Make a list of proxy lib names that we know are local and should use 'x' (instead of '*') in the output
2. (optional RFE) Add a new option to proxy provider, something like proxy_use_shadow = True/False , which would to be set to True by default for libs from list identified in step 1 and False otherwise. People could override the default setting in sssd.conf using this option if needed.
This should be relatively easy to implement.
Michal
Pushed PR: https://github.com/SSSD/sssd/pull/5221
* `master`
* ffb9ad1331ac5f5d9bf237666aff19f1def77871 - proxy: use 'x' as default pwfield only for sssd-shadowutils target
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory (sssd bug fix and enhancement update), and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://access.redhat.com/errata/RHBA-2020:4569
Description of problem: The sssd.conf(5) says: pwfield (string) The value that NSS operations that return users or groups will return for the “password” field. This option can also be set per-domain. Default: “*” (remote domains) or “x” (the files domain) However, for users returned via proxy files id_provider, * is returned. That in turn breaks PAM authentication. Version-Release number of selected component (if applicable): sssd-2.2.3-20.el8.x86_64 How reproducible: Deterministic. Steps to Reproduce: 1. Have system without SSSD configured and started. 2. Set password for user test: passwd test 3. Test that PAM authentication or user test works: echo $THE_PASSWORD | pamtester sssd-shadowutils test authenticate If you don't like to use pamtester from EPEL, just use ssh test@localhost. 4. getent passwd test, check that the output is test:x:1000:1000::/home/test:/bin/bash 5. Configure SSSD, create /etc/sssd/sssd.conf with: [sssd] domains = PROXY_PROXY services = nss [domain/PROXY_PROXY] id_provider = proxy proxy_lib_name = files proxy_pam_target = sssd-shadowutils 6. chmod 600 /etc/sssd/sssd.conf or SSSD refuses to start. 7. systemctl restart sssd 8. getent passwd test 9. echo $THE_PASSWORD | pamtester sssd-shadowutils test authenticate Actual results: test:*:1000:1000::/home/test:/bin/bash Password: pamtester: Authentication failure Expected results: test:x:1000:1000::/home/test:/bin/bash Password: pamtester: successfully authenticated Additional info: It is possible to force the expected behaviour by adding line pwfield = x to the [domain/...] section. But SSSD should obey what it says in the man page, and it should not as easily break PAM authentication of unrelated services.