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 1736796 - sssd config option "default_domain_suffix" should not cause files domain entries to be qualified, this can break sudo access
Summary: sssd config option "default_domain_suffix" should not cause files domain entr...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: sssd
Version: 8.4
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: 8.0
Assignee: Jakub Hrozek
QA Contact: sssd-qe
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-08-02 04:04 UTC by John
Modified: 2020-05-02 19:11 UTC (History)
9 users (show)

Fixed In Version: sssd-2.2.0-14.el8
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-11-05 22:34:54 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github SSSD sssd issues 5020 0 None closed sssd config option "default_domain_suffix" should not cause the files domain entries to be qualified 2020-10-13 23:54:46 UTC
Red Hat Product Errata RHSA-2019:3651 0 None None None 2019-11-05 22:35:01 UTC

Description John 2019-08-02 04:04:43 UTC 
Description of problem:

ssd config option:
  default_domain_suffix = blah 
breaks sudo.

And causes local users to show up with "implicit_files" domain.

Version-Release number of selected component (if applicable):
sssd-2.0.0-43.el8_0.3


How reproducible:
Easily.

Steps to Reproduce:
1. Configure local user to sudo eg to root without password.
2. Add "default_domain_suffix = blah" option to sssd section of sssd.conf.
3. Restart sssd.
4. Login as local user, behold as your bash prompt or whatever shows "implicit_files" domain.
5. Try to sudo to root, as allowed by sudoers. Marvel and boggle with amazement as it fails.

Actual results:
bash prompt:
[someuser@implicit_files@somehostname ~]$

sudo fail:
  sudo su -
  sudo: PAM account management error: Authentication service cannot retrieve authentication info

Expected results:
bash prompt:
[someuser@somehostname ~]$

sudo su -
#success

Additional info:
Comment 1 Jakub Hrozek 2019-08-02 09:12:18 UTC 
I can reproduce this. Thank you for the bug report, we need to get this fixed..
Comment 2 Jakub Hrozek 2019-08-02 09:37:19 UTC 
Upstream ticket:
https://pagure.io/SSSD/sssd/issue/4052
Comment 3 John 2019-08-02 10:33:03 UTC 
Np Jakub, may the force be with you.
Comment 4 Jakub Hrozek 2019-08-02 11:26:10 UTC 
PR: https://github.com/SSSD/sssd/pull/857
Comment 5 Jakub Hrozek 2019-08-02 11:28:38 UTC 
Hi Steeve,
can we please qa_ack this bug for 8.1? This bug would cause all setups that use the default_domain_suffix option to return users from the implicit files domain as fully qualified which has the potential to break e.g. sudo access for them.

The upstream PR (see comment #4) has a test, tl;dr just setting the option and then requesting a user from /etc/passwd by ID and then seeing what name is returned for that ID is enough.
Comment 6 Jakub Hrozek 2019-08-14 12:12:29 UTC 
* master: 41da9ddfd084024ba9ca20b6d3c0b531c0473231
Comment 8 Niranjan Mallapadi Raghavender 2019-08-28 02:34:09 UTC 
Reproducer:
===========
Red Hat Enterprise Linux release 8.0 (Ootpa)

sssd-common-pac-2.0.0-43.el8_0.3.x86_64
sssd-ldap-2.0.0-43.el8_0.3.x86_64
sssd-krb5-common-2.0.0-43.el8_0.3.x86_64
sssd-ad-2.0.0-43.el8_0.3.x86_64
sssd-krb5-2.0.0-43.el8_0.3.x86_64
sssd-proxy-2.0.0-43.el8_0.3.x86_64
python3-sssdconfig-2.0.0-43.el8_0.3.noarch
sssd-client-2.0.0-43.el8_0.3.x86_64
sssd-common-2.0.0-43.el8_0.3.x86_64
sssd-ipa-2.0.0-43.el8_0.3.x86_64
sssd-2.0.0-43.el8_0.3.x86_64

1. create local user foo with passwd foo
2. configure sssd.conf as below:


[sssd]
config_file_version = 2
services = nss, pam
default_domain_suffix = blah

3. restart sssd

4. give foo user sudo permissions to switch to root without password, create a
file /etc/sudoers.d/foo with below contents:

$[root@ipaqavma ~]# cat /etc/sudoers.d/foo 
foo        ALL=(ALL)       NOPASSWD: ALL

5. Login as foo user
[root@adf31c4a23fd sssd-qe-ci]# ssh foo.lab.eng.bos.redhat.com
foo.lab.eng.bos.redhat.com's password: 
Last login: Tue Aug 27 22:20:21 2019 from 10.67.116.84
[foo@implicit_files@ipaqavma ~]$ 

6. Run sudo su -
[foo@implicit_files@ipaqavma ~]$ sudo su -

We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:

    #1) Respect the privacy of others.
    #2) Think before you type.
    #3) With great power comes great responsibility.

[sudo] password for foo@implicit_files: 
Sorry, try again.


Update to latest sssd 
sssd-krb5-common-2.2.0-16.el8.x86_64
sssd-krb5-2.2.0-16.el8.x86_64
sssd-client-2.2.0-16.el8.x86_64
sssd-common-2.2.0-16.el8.x86_64
sssd-common-pac-2.2.0-16.el8.x86_64
sssd-ipa-2.2.0-16.el8.x86_64
sssd-ldap-2.2.0-16.el8.x86_64
sssd-2.2.0-16.el8.x86_64
python3-sssdconfig-2.2.0-16.el8.noarch
sssd-nfs-idmap-2.2.0-16.el8.x86_64
sssd-ad-2.2.0-16.el8.x86_64
sssd-proxy-2.2.0-16.el8.x86_64

Login again as user foo :

ssh foo.lab.eng.bos.redhat.com
foo.lab.eng.bos.redhat.com's password: 
Last login: Tue Aug 27 22:23:37 2019 from 10.67.116.84
[foo@ipaqavma ~]$ 

Run sudo su -

[foo@ipaqavma ~]$ sudo su -
Last login: Tue Aug 27 22:14:37 EDT 2019 on pts/1
Last failed login: Tue Aug 27 22:29:24 EDT 2019 from 10.67.116.84 on ssh:notty
There were 2 failed login attempts since the last successful login.
[root@ipaqavma ~]# 

sudo succeeds and after login the prompt doesn't show "implicit_domains" .
Comment 9 John 2019-09-16 04:46:45 UTC 
Hi guise ta for the prompt work to fix but is this going to be rolled out soon?

I cannot deploy EL8 vms until this issue is resolved.

Cheers,
John
Comment 10 John 2019-10-08 01:03:13 UTC 
I guess I'll be waiting until RHEL 9 for this fix to be included?
Comment 11 John 2019-10-14 02:38:23 UTC 
anyone?
Comment 12 BugMasta 2019-10-22 00:01:47 UTC 

Fixed In Version:	sssd-2.2.0-14.el8



WHEN IS THIS GOING TO BE RELEASED?
ARE WE JUST GOING TO SIT ON IT FOREVER ARE WE?
Comment 14 errata-xmlrpc 2019-11-05 22:34:54 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/RHSA-2019:3651
Comment 15 John 2019-11-14 05:40:07 UTC 
Ah, it's out. TY.
Sorry for being so impatient and rude there.
Note You need to log in before you can comment on or make changes to this bug.