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 1428866 - Using ad_enabled_domains configuration option in sssd.conf causes nameservice lookups to fail.
Summary: Using ad_enabled_domains configuration option in sssd.conf causes nameservice...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: sssd
Version: 7.3
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Sumit Bose
QA Contact: shridhar
URL:
Whiteboard:
Depends On: 1457926
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-03-03 14:30 UTC by afox@redhat.com
Modified: 2021-07-27 15:29 UTC (History)
12 users (show)

Fixed In Version: sssd-1.15.2-21.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-08-01 09:04:18 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github SSSD sssd issues 4391 0 None closed sssd_be crashes if ad_enabled_domains is selected 2021-02-16 12:29:12 UTC
Red Hat Product Errata RHEA-2017:2294 0 normal SHIPPED_LIVE sssd bug fix and enhancement update 2017-08-01 12:39:55 UTC

Description afox@redhat.com 2017-03-03 14:30:05 UTC
Description of problem:
Using ad_enabled_domains configuration option in sssd.conf causes nameservice lookups to fail. 

Version-Release number of selected component (if applicable):
sssd-1.14.0-43.el7_3.11.x86_64

How reproducible:
Customer can reproduce at will.

Steps to Reproduce:
1. Add autofs_provider = ad and ad_enabled_domains = nam.nsroot.net, eur.nsroot.net, apac.nsroot.net to sssd.conf
2. Restart sssd.
3. Attempt to login or perform any operation that requires nameservice lookup.

Actual results:
Where user is already logged in, performing ls -la shows:
-bash-4.2$ ls -la
total 12
drwxrwxrwt.  4 root      root      4096 Feb  6 13:19 .
drwxr-xr-x. 21 root      root      4096 Feb  6 00:03 ..
-rw-r--r--.  1 500008636 500008636    0 Jan 24 06:39 a
-rw-r--r--.  1 500008636 500008636    0 Jan 24 06:39 b
-rw-r--r--.  1 500008636 500008636    0 Jan 24 06:39 c
-rw-------.  1 root      root       225 Jan 18 10:24 host_0
drwx------.  3 root      root        16 Feb  6 05:03 systemd-private-6c756b8f1e52474d914f7692da647efc-vmtoolsd.service-oFTNyO
drwxr-xr-x.  2 500008636 500008636   22 Feb  6 13:20 test

Similarly, if user tries to login using ssh -l then you see no prompt for password at all. It simply fails. 

For the case of SSSD running in the nam.nsroot.net domain, the SSSD process dumps core (core file attached). 

Expected results:
When the ad_enabled_domains option is commented out the lookups work as expected, as do logins:

-bash-4.2$ ls -la
total 51020
drwxrwxrwt.  4 root                   root          4096 Feb  9 09:23 .
drwxr-xr-x. 21 root                   root          4096 Feb  6 00:03 ..
-rw-r--r--.  1 jw83113.net 500008636        0 Jan 24 06:39 a
-rw-r--r--.  1 jw83113.net 500008636        0 Jan 24 06:39 b
-rw-r--r--.  1 jw83113.net 500008636        0 Jan 24 06:39 c
-rw-------.  1 root                   root           225 Jan 18 10:24 host_0
-rw-------.  1 root                   root      52224828 Feb  9 09:22 sosreport-JWaterhouse.01674199-20170209092050.tar.xz
-rw-r--r--.  1 root                   root            33 Feb  9 09:23 sosreport-JWaterhouse.01674199-20170209092050.tar.xz.md5
drwx------.  3 root                   root            16 Feb  6 05:03 systemd-private-6c756b8f1e52474d914f7692da647efc-vmtoolsd.service-oFTNyO
drwxr-xr-x.  2 jw83113.net 500008636       22 Feb  6 13:20 test

Additional info:
When a failed lookup occurs, the following is seen in the logs:

(Wed Jan 25 10:14:47 2017) [sssd[nss]] [nss_cmd_getpwuid_search] (0x0100): Requesting info for [500008636.NET]
(Wed Jan 25 10:14:49 2017) [sssd[nss]] [nss_cmd_getpwuid_search] (0x0100): Requesting info for [500008636.NET]
(Wed Jan 25 10:14:49 2017) [sssd[nss]] [nss_cmd_getpwuid_search] (0x0100): Requesting info for [500008636.net]
(Wed Jan 25 10:14:49 2017) [sssd[nss]] [sss_dp_get_reply] (0x0010): The Data Provider returned an error [org.freedesktop.sssd.Error.DataProvider.Fatal]
(Wed Jan 25 10:14:49 2017) [sssd[nss]] [nss_cmd_getby_dp_callback] (0x0040): Unable to get information from Data Provider
Error: 3, 5, Failed to get reply from Data Provider

Two sosreports are attached:
(sosreport-JWaterhouse.01674199-20170209092050.tar.xz) contains the log files for the failure case with the ad_enabled_domains option enabled.
The second (sosreport-JWaterhouse.01674199-20170209092612.tar.xz) contains the log files for the success case with the ad_enabled_domains option disabled.

Comment 5 Sumit Bose 2017-03-31 13:04:08 UTC
I can reproduce this if the forest root is not in the list of enabled domains. While looking up the domain topology from a DC of the _forest root_ the crash happens after to forest root got disabled. Will investigate further.

Comment 8 Jakub Hrozek 2017-04-04 11:48:25 UTC
Upstream ticket:
https://pagure.io/SSSD/sssd/issue/3361

Comment 15 Jakub Hrozek 2017-04-28 07:12:08 UTC
master:
    feeabf273aa7af580552366ce58655e6a482a0cd
    712e5b2e4465812c00a8667c75813322373bc657
sssd-1-14:
    4e23f5398859ff23a4daf2da580bf2a40cc2023d
    b5af4ce0bdfa05841c0a856868a7961269cd7bf4
sssd-1-13:
    185c804089b9f5a537cdfb3cfc5528fba4dcba1e
    31d22b8543366b545dc4b7273e9bcdbf65f8f381

Comment 17 shridhar 2017-05-27 19:08:51 UTC
Pls Share the verification step

Comment 18 Sumit Bose 2017-06-06 08:34:50 UTC
To verify this issue setup an AD forest with multiple domains in a forest. Then add the ad_enabled_domains option to sssd.conf and some domains from the forest but not the forest root to the list. Older versions of SSSD will show the behavior as shown in the description of this ticket while with the fix user and group names will be displayed properly.

Comment 19 shridhar 2017-06-23 11:21:16 UTC
verified with:

[root@shr7-permanent ~]# rpm -q sssd
sssd-1.15.2-50.el7.x86_64
[root@shr7-permanent ~]# cat /etc/sssd/sssd.conf 

[sssd]
domains = childb.sssd16.qe
config_file_version = 2
services = nss, pam

[domain/childb.sssd16.qe]
ad_domain = childb.sssd16.qe
krb5_realm = CHILDB.SSSD16.QE
realmd_tags = manages-system joined-with-adcli 
cache_credentials = True
id_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = True
use_fully_qualified_names = True
fallback_homedir = /home/%u@%d
access_provider = ad
#ad_enabled_domains = first.sssd16.qe, sssd16.qe, childb.sssd16.qe
ad_enabled_domains = first.sssd16.qe, childb.sssd16.qe
debug_level = 9

[root@shr7-permanent ~]# service sssd stop ; rm -rf /var/lib/sss/db/* ; rm -rf /var/log/sssd/* ; date ; service sssd start 
Redirecting to /bin/systemctl stop sssd.service
Fri Jun 23 06:20:03 EDT 2017
Redirecting to /bin/systemctl start sssd.service

[root@shr7-permanent ~]# id administrator.qe
uid=1170600500(administrator.qe) gid=1170600513(domain users.qe) groups=1170600513(domain users.qe),1170600520(group policy creator owners.qe),1170600512(domain admins.qe),1170600572(denied rodc password replication group.qe)

[root@shr7-permanent ~]# id administrator.qe
uid=130200500(administrator.qe) gid=130200500(administrator.qe) groups=130200500(administrator.qe),130200513


[root@shr7-permanent ~]# id administrator.qe
uid=130200500(administrator.qe) gid=130200500(administrator.qe) groups=130200500(administrator.qe),130200512(domain admins.qe),130200513(domain users.qe),130200520(group policy creator owners.qe)
[root@shr7-permanent ~]# ssh -l administrator.qe localhost
administrator.qe@localhost's password: 
Creating home directory for administrator.qe.
Last failed login: Fri Jun 23 07:02:17 EDT 2017 from ::1 on ssh:notty
There were 3 failed login attempts since the last successful login.
[administrator.qe@shr7-permanent ~]$ logout
Connection to localhost closed.
 
[root@shr7-permanent ~]# ssh -l  fu1.qe  localhost
fu1.qe@localhost's password: 
Creating home directory for fu1.qe.

Comment 22 errata-xmlrpc 2017-08-01 09:04:18 UTC
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-2017:2294


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