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
Upstream ticket: https://pagure.io/SSSD/sssd/issue/3979
* master: * 9d63616 * 1eb3ae1 * sssd-1-16: * 2c97edb * eaceb6a
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