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.
Descriptionafox@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.
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.
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.
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