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.
Description of problem:
In some situations we recommend "ldap_deref_threshold=0" setting for sssd for performance enhancement.
This setting when applied breaks ssh access to IdM clients, as it seems sssd's HBAC code doesn't work when de-reference is disabled.
Version-Release number of selected component (if applicable):
How reproducible:
Steps to Reproduce:
1. enroll a machine to and IdM domain
2. set "ldap_deref_threshold=0" in sssd.conf and restart sssd
3. try to ssh to this machine
Actual results:
SSH access fails and errors similar to the below is captured on sssd debug logs:
~~~
(Sun Feb 24 14:27:03 2019) [sssd[be[example.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [objectClass]
(Sun Feb 24 14:27:03 2019) [sssd[be[example.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [cn]
(Sun Feb 24 14:27:03 2019) [sssd[be[example.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [fqdn]
(Sun Feb 24 14:27:03 2019) [sssd[be[example.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [serverHostname]
(Sun Feb 24 14:27:03 2019) [sssd[be[example.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipaSshPubKey]
(Sun Feb 24 14:27:03 2019) [sssd[be[example.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipaUniqueID]
(Sun Feb 24 14:27:03 2019) [sssd[be[example.com]]] [sdap_process_result] (0x2000): Trace: sh[0x55a082395c50], connected[1], ops[0x55a0823cfab0], ldap[0x55a08238ae60]
(Sun Feb 24 14:27:03 2019) [sssd[be[example.com]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT]
(Sun Feb 24 14:27:03 2019) [sssd[be[example.com]]] [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no errmsg set
(Sun Feb 24 14:27:03 2019) [sssd[be[example.com]]] [sdap_get_generic_op_finished] (0x2000): Total count [0]
(Sun Feb 24 14:27:03 2019) [sssd[be[example.com]]] [sdap_op_destructor] (0x2000): Operation 28 finished
(Sun Feb 24 14:27:03 2019) [sssd[be[example.com]]] [ipa_host_info_done] (0x0020): Server does not support deref
(Sun Feb 24 14:27:03 2019) [sssd[be[example.com]]] [sdap_id_op_destroy] (0x4000): releasing operation connection
(Sun Feb 24 14:27:03 2019) [sssd[be[example.com]]] [ipa_pam_access_handler_done] (0x0020): Unable to fetch rules [5]: Input/output error
(Sun Feb 24 14:27:03 2019) [sssd[be[example.com]]] [dp_req_done] (0x0400): DP Request [PAM Account #7]: Request handler finished [0]: Success
(Sun Feb 24 14:27:03 2019) [sssd[be[example.com]]] [_dp_req_recv] (0x0400): DP Request [PAM Account #7]: Receiving request data.
(Sun Feb 24 14:27:03 2019) [sssd[be[example.com]]] [dp_req_destructor] (0x0400): DP Request [PAM Account #7]: Request removed.
(Sun Feb 24 14:27:03 2019) [sssd[be[example.com]]] [dp_req_destructor] (0x0400): Number of active DP request: 0
(Sun Feb 24 14:27:03 2019) [sssd[be[example.com]]] [dp_pam_reply] (0x1000): DP Request [PAM Account #7]: Sending result [4][example.com]
(Sun Feb 24 14:27:03 2019) [sssd[be[example.com]]] [sdap_process_result] (0x2000): Trace: sh[0x55a082395c50], connected[1], ops[(nil)], ldap[0x55a08238ae60]
(Sun Feb 24 14:27:03 2019) [sssd[be[example.com]]] [sdap_process_result] (0x2000): Trace: end of ldap_result list
~~~
Expected results:
SSH access works fine (honoring HBAC rules) while derefrence control is set to zero.
Additional info:
Just for recording, in case SSSD requires to use deref control and hit performance issue (long lasting ldap req) then we could investigate an improvement on DS side https://pagure.io/389-ds-base/issue/49951
Build used for verification:
[root@ipaqavmh ~]# rpm -qa ipa-server sssd
ipa-server-4.6.5-8.el7.x86_64
sssd-1.16.4-13.el7.x86_64
[root@ipaqavmh ~]#
Since I am still seeing authentication failures, after adding ldap_deref_threshold=0
Marking BZ failed QA
Verification procedure
On Server
[root@ipaqavmh ~]# rpm -qa ipa-* sssd
ipa-server-4.6.5-8.el7.x86_64
ipa-server-common-4.6.5-8.el7.noarch
ipa-client-4.6.5-8.el7.x86_64
sssd-1.16.4-14.el7.x86_64
ipa-common-4.6.5-8.el7.noarch
ipa-client-common-4.6.5-8.el7.noarch
ipa-server-dns-4.6.5-8.el7.noarch
[root@ipaqavmh ~]#
[root@ipaqavmh ~]# grep -nr "ldap_deref_threshold=0" /etc/sssd/sssd.conf
14:ldap_deref_threshold=0
[root@ipaqavmh ~]#
[root@ipaqavmh ~]# ipa hbacrule-find
--------------------
2 HBAC rules matched
--------------------
Rule name: allow_all
User category: all
Host category: all
Service category: all
Description: Allow all users to access any host from any host
Enabled: TRUE
Rule name: allow_systemd-user
User category: all
Host category: all
Description: Allow pam_systemd to run user@.service to create a system user session
Enabled: TRUE
----------------------------
Number of entries returned 2
----------------------------
[root@ipaqavmh ~]#
[root@ipaqavmh ~]# ipa user-add testuser2 --first test --last user2 --password
Password:
Enter Password again to verify:
----------------------
Added user "testuser2"
----------------------
User login: testuser2
First name: test
Last name: user2
Full name: test user2
Display name: test user2
Initials: tu
Home directory: /home/testuser2
GECOS: test user2
Login shell: /bin/sh
Principal name: testuser2
Principal alias: testuser2
User password expiration: 20190520081820Z
Email address: testuser2
UID: 1737200003
GID: 1737200003
Password: True
Member of groups: ipausers
Kerberos keys available: True
##################################################################
On Client
[root@ipaqavmc ~]# rpm -qa ipa-* sssd
ipa-client-4.6.5-8.el7.x86_64
sssd-1.16.4-14.el7.x86_64
ipa-common-4.6.5-8.el7.noarch
ipa-client-common-4.6.5-8.el7.noarch
[root@ipaqavmc ~]#
[root@ipaqavmc ~]# ssh testuser2.test
Password:
Password expired. Change your password now.
Current Password:
Password change failed. Server message: Old password not accepted.
Password:
Password:
Password expired. Change your password now.
Current Password:
New password:
Retype new password:
Last failed login: Mon May 20 04:20:36 EDT 2019 from ipaqavmc.idmqe.lab.eng.bos.redhat.com on ssh:notty
There were 2 failed login attempts since the last successful login.
-sh-4.2$
-sh-4.2$ whoami
testuser2
Based on above observations, marking the bugzilla verified.
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, 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/RHSA-2019:2177