Bug 1479983 - id root triggers an LDAP lookup
id root triggers an LDAP lookup
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: sssd (Show other bugs)
7.3
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: SSSD Maintainers
shridhar
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2017-08-09 16:53 EDT by Jakub Hrozek
Modified: 2018-04-10 13:15 EDT (History)
9 users (show)

See Also:
Fixed In Version: sssd-1.16.0-1.el7
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2018-04-10 13:13:24 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2018:0929 None None None 2018-04-10 13:15 EDT

  None (edit)
Description Jakub Hrozek 2017-08-09 16:53:05 EDT
This bug is created as a clone of upstream ticket:
https://pagure.io/SSSD/sssd/issue/3460

This looks even like a regression to me, because with today's master, calling initgroups for root triggers an LDAP lookup:

```
(Thu Aug  3 10:14:12 2017) [sssd[nss]] [nss_getby_name] (0x0400): Input name: root
(Thu Aug  3 10:14:12 2017) [sssd[nss]] [cache_req_set_plugin] (0x2000): CR #0: Setting "Initgroups by name" plugin
(Thu Aug  3 10:14:12 2017) [sssd[nss]] [cache_req_send] (0x0400): CR #0: New request 'Initgroups by name'
(Thu Aug  3 10:14:12 2017) [sssd[nss]] [cache_req_process_input] (0x0400): CR #0: Parsing input name [root]
(Thu Aug  3 10:14:12 2017) [sssd[nss]] [sss_parse_name_for_domains] (0x0200): name 'root' matched without domain, user is root
(Thu Aug  3 10:14:12 2017) [sssd[nss]] [cache_req_set_name] (0x0400): CR #0: Setting name [root]
(Thu Aug  3 10:14:12 2017) [sssd[nss]] [cache_req_select_domains] (0x0400): CR #0: Performing a multi-domain search
(Thu Aug  3 10:14:12 2017) [sssd[nss]] [cache_req_search_domains] (0x0400): CR #0: Search will check the cache and check the data provider
(Thu Aug  3 10:14:12 2017) [sssd[nss]] [cache_req_validate_domain_type] (0x2000): Request type POSIX-only for domain ipa.test type POSIX is valid
(Thu Aug  3 10:14:12 2017) [sssd[nss]] [cache_req_set_domain] (0x0400): CR #0: Using domain [ipa.test]
(Thu Aug  3 10:14:12 2017) [sssd[nss]] [cache_req_prepare_domain_data] (0x0400): CR #0: Preparing input data for domain [ipa.test] rules
(Thu Aug  3 10:14:12 2017) [sssd[nss]] [cache_req_search_send] (0x0400): CR #0: Looking up root@ipa.test
(Thu Aug  3 10:14:12 2017) [sssd[nss]] [cache_req_search_ncache] (0x0400): CR #0: Checking negative cache for [root@ipa.test]
(Thu Aug  3 10:14:12 2017) [sssd[nss]] [sss_ncache_check_str] (0x2000): Checking negative cache for [NCE/USER/ipa.test/root@ipa.test]
(Thu Aug  3 10:14:12 2017) [sssd[nss]] [cache_req_search_ncache] (0x0400): CR #0: [root@ipa.test] does not exist (negative cache)
(Thu Aug  3 10:14:12 2017) [sssd[nss]] [cache_req_validate_domain_type] (0x2000): Request type POSIX-only for domain win.trust.test type POSIX is valid
(Thu Aug  3 10:14:12 2017) [sssd[nss]] [cache_req_set_domain] (0x0400): CR #0: Using domain [win.trust.test]
(Thu Aug  3 10:14:12 2017) [sssd[nss]] [cache_req_prepare_domain_data] (0x0400): CR #0: Preparing input data for domain [win.trust.test] rules
(Thu Aug  3 10:14:12 2017) [sssd[nss]] [cache_req_search_send] (0x0400): CR #0: Looking up root@win.trust.test
(Thu Aug  3 10:14:12 2017) [sssd[nss]] [cache_req_search_ncache] (0x0400): CR #0: Checking negative cache for [root@win.trust.test]
(Thu Aug  3 10:14:12 2017) [sssd[nss]] [sss_ncache_check_str] (0x2000): Checking negative cache for [NCE/USER/win.trust.test/root@win.trust.test]
(Thu Aug  3 10:14:12 2017) [sssd[nss]] [cache_req_search_ncache] (0x0400): CR #0: [root@win.trust.test] is not present in negative cache
(Thu Aug  3 10:14:12 2017) [sssd[nss]] [cache_req_search_cache] (0x0400): CR #0: Looking up [root@win.trust.test] in cache
(Thu Aug  3 10:14:12 2017) [sssd[nss]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x886c30

(Thu Aug  3 10:14:12 2017) [sssd[nss]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x886cf0

(Thu Aug  3 10:14:12 2017) [sssd[nss]] [ldb] (0x4000): Running timer event 0x886c30 "ltdb_callback"

(Thu Aug  3 10:14:12 2017) [sssd[nss]] [ldb] (0x4000): Destroying timer event 0x886cf0 "ltdb_timeout"

(Thu Aug  3 10:14:12 2017) [sssd[nss]] [ldb] (0x4000): Ending timer event 0x886c30 "ltdb_callback"

(Thu Aug  3 10:14:12 2017) [sssd[nss]] [sysdb_search_override_by_name] (0x0400): No user override found for name [root@win.trust.test].
(Thu Aug  3 10:14:12 2017) [sssd[nss]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x884f50

(Thu Aug  3 10:14:12 2017) [sssd[nss]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x887dd0

(Thu Aug  3 10:14:12 2017) [sssd[nss]] [ldb] (0x4000): Running timer event 0x884f50 "ltdb_callback"

(Thu Aug  3 10:14:12 2017) [sssd[nss]] [ldb] (0x4000): Destroying timer event 0x887dd0 "ltdb_timeout"

(Thu Aug  3 10:14:12 2017) [sssd[nss]] [ldb] (0x4000): Ending timer event 0x884f50 "ltdb_callback"

(Thu Aug  3 10:14:12 2017) [sssd[nss]] [cache_req_search_cache] (0x0400): CR #0: Object [root@win.trust.test] was not found in cache
(Thu Aug  3 10:14:12 2017) [sssd[nss]] [cache_req_search_dp] (0x0400): CR #0: Looking up [root@win.trust.test] in data provider
```

I even have explicit filter_users = root in the nss section, but it doesn't appear to work
Comment 2 Jakub Hrozek 2017-08-18 04:49:38 EDT
To test, please see the opening comment. The short version of that comment is, run "id root" in a setup that also includes subdomains (any subdomains, it doesn't have to be IPA-AD trust, it can also be AD-AD trust)

Before the patch, you should see the subdomain back end being queried for the root user. After the patch, the request should be shortcut in the NSS responder already and there should be no search towards the back end side.
Comment 3 Jakub Hrozek 2017-08-28 15:04:59 EDT
master:
 * 6c3841099addb84bf3e9a2f85e96dffae1b94623
 * 5883b99fa0d13368f6e79fdb40b6637d36ed1801
 * 137e105ac8ca3476d2f74d24ae13860774937000
 * b4b3d0642120ca05f63959fe2f317a6b93031929
 * 3ad33ca77044f9a9d18f7def271b0beb180e567b
 * 431c7508e0d256b9c712cb9dcb9aa4cb635f4a0b
 * 8888d7a46371ddd2c2514c3e81b58bb1090902a2
 * 9908bdc9755e744c3e2c7c746a4edf95f9083ef5
 * e54764d62bfcc48770d9b2578132979aa58636e5
 * 1e7b7da3aa56060c26f8ba1c08318cdee77753ea
 * b54d79cf3c8017e186b5ea7cdc383746233db39b
Comment 5 shridhar 2018-01-16 05:46:28 EST
verified with
[root@cloud-qe-12 ~]# rpm -q sssd 
sssd-1.16.0-14.el7.x86_64

[root@cloud-qe-12 ~]# cat /etc/sssd/sssd.conf

[sssd]
config_file_version = 2
services = nss, pam
domains = sssdad.com

[domain/sssdad.com]
debug_level = 0x0400
id_provider = ad
use_fully_qualified_names = True
fallback_homedir = /home/%d/%u

[nss]
debug_level = 9

[root@cloud-qe-12 ~]# service sssd stop ; rm -rf /var/lib/sss/db/* ; rm -rf /var/log/sssd/* ; service sssd start ; sleep 30
Redirecting to /bin/systemctl stop sssd.service
Redirecting to /bin/systemctl start sssd.service

[root@cloud-qe-12 ~]# date ; id root
Tue Jan 16 05:38:07 EST 2018
uid=0(root) gid=0(root) groups=0(root)


from /var/log/sssd/sssd_nss.log
<snip>
(Tue Jan 16 05:38:07 2018) [sssd[nss]] [nss_getby_name] (0x0400): Input name: root
(Tue Jan 16 05:38:07 2018) [sssd[nss]] [cache_req_set_plugin] (0x2000): CR #1: Setting "Initgroups by name" plugin
(Tue Jan 16 05:38:07 2018) [sssd[nss]] [cache_req_send] (0x0400): CR #1: New request 'Initgroups by name'
(Tue Jan 16 05:38:07 2018) [sssd[nss]] [cache_req_process_input] (0x0400): CR #1: Parsing input name [root]
(Tue Jan 16 05:38:07 2018) [sssd[nss]] [sss_parse_name_for_domains] (0x0200): name 'root' matched without domain, user is root
(Tue Jan 16 05:38:07 2018) [sssd[nss]] [cache_req_set_name] (0x0400): CR #1: Setting name [root]
(Tue Jan 16 05:38:07 2018) [sssd[nss]] [cache_req_select_domains] (0x0400): CR #1: Performing a multi-domain search
(Tue Jan 16 05:38:07 2018) [sssd[nss]] [cache_req_search_domains] (0x0400): CR #1: Search will check the cache and check the data provider
(Tue Jan 16 05:38:07 2018) [sssd[nss]] [cache_req_validate_domain_type] (0x2000): Request type POSIX-only for domain sssdad.com type POSIX is valid
(Tue Jan 16 05:38:07 2018) [sssd[nss]] [cache_req_validate_domain_type] (0x2000): Request type POSIX-only for domain child1.sssdad.com type POSIX is valid
(Tue Jan 16 05:38:07 2018) [sssd[nss]] [cache_req_validate_domain_type] (0x2000): Request type POSIX-only for domain sssdad_tree.com type POSIX is valid
(Tue Jan 16 05:38:07 2018) [sssd[nss]] [cache_req_global_ncache_add] (0x2000): CR #1: This request type does not support global negative cache
(Tue Jan 16 05:38:07 2018) [sssd[nss]] [cache_req_process_result] (0x0400): CR #1: Finished: Not found
(Tue Jan 16 05:38:07 2018) [sssd[nss]] [sss_domain_get_state] (0x1000): Domain child1.sssdad.com is Active
(Tue Jan 16 05:38:07 2018) [sssd[nss]] [sss_domain_get_state] (0x1000): Domain sssdad_tree.com is Active
(Tue Jan 16 05:38:07 2018) [sssd[nss]] [nss_protocol_done] (0x4000): Sending reply: not found
(Tue Jan 16 05:38:07 2018) [sssd[nss]] [client_recv] (0x0200): Client disconnected!
(Tue Jan 16 05:38:07 2018) [sssd[nss]] [client_close_fn] (0x2000): Terminated client [0x565108d69e80][21]

</snip>

Domain logs have shown no activity about searching root user in AD-domains and subdomains

[root@cloud-qe-12 ~]# egrep root /var/log/sssd/sssd_sssdad.com.log 
(Tue Jan 16 05:37:29 2018) [sssd[be[sssdad.com]]] [ldb] (0x0400): asq: Unable to register control with rootdse!
(Tue Jan 16 05:37:29 2018) [sssd[be[sssdad.com]]] [sdap_get_map] (0x0400): Option ldap_rootdse_last_usn has value highestCommittedUSN
(Tue Jan 16 05:37:30 2018) [sssd[be[sssdad.com]]] [sdap_get_map] (0x0400): Option ldap_rootdse_last_usn has value highestCommittedUSN
(Tue Jan 16 05:37:30 2018) [sssd[be[sssdad.com]]] [sdap_get_map] (0x0400): Option ldap_rootdse_last_usn has value highestCommittedUSN
Comment 8 errata-xmlrpc 2018-04-10 13:13:24 EDT
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/RHEA-2018:0929

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