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 1211830 - external users do not resolve with "default_domain_suffix" set in IPA server sssd.conf
Summary: external users do not resolve with "default_domain_suffix" set in IPA server ...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: sssd
Version: 7.1
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: SSSD Maintainers
QA Contact: Kaushik Banerjee
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-04-15 02:44 UTC by Aron Parsons
Modified: 2020-05-02 18:03 UTC (History)
13 users (show)

Fixed In Version: sssd-1.13.0-0.1.alpha.el7
Doc Type: Bug Fix
Doc Text:
Cause: If default_domain_suffix was set on the server side and hence fully-qualified names are used for the IPA domain the extdom plugin that communicates between IPA clients and servers returned fully-qualified names for IPA objects as well. Consequence: There were areas of code that didn't handle this correctly and always qualified IPA names. Fix: The IPA names are not qualified on the client side if the server already qualified them Result: IPA group members resolve even if default_domain_suffix is used on the server side.
Clone Of:
Environment:
Last Closed: 2015-11-19 11:38:03 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
client log (1.01 MB, text/plain)
2015-04-20 16:31 UTC, Aron Parsons 		no flags Details
client sssd log (163.05 KB, text/plain)
2015-04-22 01:32 UTC, Aron Parsons 		no flags Details
server sssd log (5.22 MB, text/plain)
2015-04-22 01:32 UTC, Aron Parsons 		no flags Details
dirsrv access log (504.17 KB, text/plain)
2015-04-22 01:33 UTC, Aron Parsons 		no flags Details
sssd logs (149.51 KB, application/x-gzip)
2015-04-23 00:58 UTC, Aron Parsons 		no flags Details
sssd and dirsrv logs (389.78 KB, application/x-gzip)
2015-04-27 00:23 UTC, Aron Parsons 		no flags Details
exop-backtrace (8.53 KB, text/plain)
2015-04-29 03:39 UTC, Aron Parsons 		no flags Details
segfault-patch (944 bytes, patch)
2015-04-29 03:40 UTC, Aron Parsons 		no flags Details | Diff
Show Obsolete (5) View All


Links
System ID Private Priority Status Summary Last Updated
Github SSSD sssd issues 3688 0 None closed external users do not resolve with "default_domain_suffix" set in IPA server sssd.conf 2020-12-03 10:06:55 UTC
Red Hat Product Errata RHSA-2015:2355 0 normal SHIPPED_LIVE Low: sssd security, bug fix, and enhancement update 2015-11-19 10:27:42 UTC

Description Aron Parsons 2015-04-15 02:44:02 UTC 
Description of problem:
When in an AD trust, IPA fails to return user information from the extdom call if a external user is a member of an IPA group with the "default_domain_suffix" setting configured in the IPA server's sssd.conf.  The user information is complete and accurate when viewed on the IPA server itself, but no information is returned to a client requesting that user, leading to complete identity failure on clients.

"default_domain_suffix" is set on the IPA servers, along with all the clients, as a convenience for administrators and users to avoid using their fully-qualified names.  Although we can work around this bug by not setting that value, we'd like to not have a unique configuration only on the IPA servers.


Version-Release number of selected component (if applicable):
ipa-server-4.1.0-18.el7_1.3.x86_64
sssd-1.12.2-58.el7_1.6.x86_64


How reproducible:
always


Steps to Reproduce:
* setup an AD trust with POSIX attributes
* create user "test1"
* add user to "biggroup"
* ensure POSIX attributes are set on both the user and group

* on the IPA server, set default_domain_suffix in [sssd] section:
grep default_domain_suffix /etc/sssd/sssd.conf

ipa group-del ad_biggroup
ipa group-del external_biggroup

service sssd stop; rm -f /var/lib/sss/{db,mc}/*; service sssd start

id test1

ipa group-add --desc 'external - biggroup' --external external_biggroup
ipa group-add-member --users='' --groups='' --external 'EXAMPLE\biggroup' external_biggroup

ipa group-add --desc 'ad - biggroup' ad_biggroup
ipa group-add-member --users='' --groups=external_biggroup ad_biggroup

service sssd stop
rm -f /var/lib/sss/{db,mc}/*
rm -f /var/log/sssd/*
service sssd start

id test1


* on the IPA client:
service sssd stop; rm -f /var/lib/sss/{db,mc}/*; service sssd start; id test1


Actual results:
* on the IPA server without default_domain_suffix on the server:
grep default_domain_suffix /etc/sssd/sssd.conf; id test1
#default_domain_suffix = example.com
uid=10000(test1) gid=10000(domain users) groups=10000(domain users),730800023(ad_biggroup),10001(biggroup)

* on the IPA server with default_domain_suffix on the server:
grep default_domain_suffix /etc/sssd/sssd.conf; id test1
default_domain_suffix = example.com
uid=10000(test1) gid=10000(domain users) groups=10000(domain users),730800023(ad_biggroup),10001(biggroup)

* on the IPA client without default_domain_suffix on the server:
service sssd stop; rm -f /var/lib/sss/{db,mc}/*; service sssd start; id test1
Redirecting to /bin/systemctl stop  sssd.service
Redirecting to /bin/systemctl start  sssd.service
uid=10000(test1) gid=10000(domain users) groups=10000(domain users),730800023(ad_biggroup),10001(biggroup)

* on the IPA client with default_domain_suffix on the server:
service sssd stop; rm -f /var/lib/sss/{db,mc}/*; service sssd start; id test1
Redirecting to /bin/systemctl stop  sssd.service
Redirecting to /bin/systemctl start  sssd.service
id: test1: no such user


Expected results:
* on the IPA server:
grep default_domain_suffix /etc/sssd/sssd.conf; id test1
default_domain_suffix = example.com
uid=10000(test1) gid=10000(domain users) groups=10000(domain users),730800023(ad_biggroup),10001(biggroup)

* on the IPA client:
service sssd stop; rm -f /var/lib/sss/{db,mc}/*; service sssd start; id test1
Redirecting to /bin/systemctl stop  sssd.service
Redirecting to /bin/systemctl start  sssd.service
uid=10000(test1) gid=10000(domain users) groups=10000(domain users),730800023(ad_biggroup),10001(biggroup)


Additional info:
I put this bug under ipa because it only seems related to the extdom plugin in IPA.  The user information is complete when querying on the IPA server, though the bug is triggered by the sssd setting.  So not sure exactly in which component the problem lies.

This is only an issue with sssd 1.12+ where the complete group information is returned via the IPA extdom plugin, so technically it is a regression because identity information is not returned and existing IPA environments are broken.  Prior to sssd 1.12, where group information was only completed via PAC, RHEL6 and RHEL7 clients had no issue resolving users' identities.
Comment 2 Sumit Bose 2015-04-17 16:21:36 UTC 
I changed the component to SSSD becasue I think the issue is related to the handling of the groups returned by the extdom plugin on the client.

To confirm my assumption I have a question about

> * on the IPA server with default_domain_suffix on the server:
> grep default_domain_suffix /etc/sssd/sssd.conf; id test1
> default_domain_suffix = example.com
> uid=10000(test1) gid=10000(domain users)  groups=10000(domain users),730800023(ad_biggroup),10001(biggroup)

Can you re-check in this configuration if 'ad_biggroup' is really returned with the short name or if it is returned as 'ad_biggroup'? Please remove the cache on the server before testing.
Comment 3 Aron Parsons 2015-04-20 16:29:19 UTC 
(In reply to Sumit Bose from comment #2)
> I changed the component to SSSD becasue I think the issue is related to the
> handling of the groups returned by the extdom plugin on the client.
> 
> To confirm my assumption I have a question about
> 
> > * on the IPA server with default_domain_suffix on the server:
> > grep default_domain_suffix /etc/sssd/sssd.conf; id test1
> > default_domain_suffix = example.com
> > uid=10000(test1) gid=10000(domain users)  groups=10000(domain users),730800023(ad_biggroup),10001(biggroup)
> 
> Can you re-check in this configuration if 'ad_biggroup' is really returned
> with the short name or if it is returned as 'ad_biggroup'? Please
> remove the cache on the server before testing.

It is returning just the short name:

# server
[root@ipa01 ~]# grep -e default_domain_suffix -e qualified /etc/sssd/sssd.conf; service sssd stop; rm -f /var/lib/sss/{db,mc}/*; service sssd start; id test1
#use_fully_qualified_names = true
#default_domain_suffix = example.com
Redirecting to /bin/systemctl stop  sssd.service
Redirecting to /bin/systemctl start  sssd.service
uid=10000(test1) gid=10000(domain users) groups=10000(domain users),730800023(ad_biggroup),10001(biggroup)

# client
[root@client01 ~]# grep -e default_domain_suffix -e qualified /etc/sssd/sssd.conf; service sssd stop; rm -f /var/lib/sss/{db,mc}/*; service sssd start; id test1
#use_fully_qualified_names = true
default_domain_suffix = example.com
Redirecting to /bin/systemctl stop  sssd.service
Redirecting to /bin/systemctl start  sssd.service
uid=10000(test1) gid=10000(domain users) groups=10000(domain users),730800023(ad_biggroup),10001(biggroup)


However, here's an interesting bit I stumbled upon while testing this and verifying that "ad_biggroup" was coming back in the tux.example.com domain.  If "use_fully_qualified_names" is enabled on *both* the client and server, user information is returned, but "ad_biggroup.com" is suspiciously missing from the group list on the client:

# server
[root@ipa01 ~]# grep -e default_domain_suffix -e qualified /etc/sssd/sssd.conf; service sssd stop; rm -f /var/lib/sss/{db,mc}/*; service sssd start; id test1
use_fully_qualified_names = true
default_domain_suffix = example.com
Redirecting to /bin/systemctl stop  sssd.service
Redirecting to /bin/systemctl start  sssd.service
uid=10000(test1) gid=10000(domain users) groups=10000(domain users),730800023(ad_biggroup.com),10001(biggroup)

# client
[root@client01 ~]# grep -e default_domain_suffix -e qualified /etc/sssd/sssd.conf; service sssd stop; rm -f /var/lib/sss/{db,mc}/*; service sssd start; id test1
use_fully_qualified_names = true
default_domain_suffix = example.com
Redirecting to /bin/systemctl stop  sssd.service
Redirecting to /bin/systemctl start  sssd.service
uid=10000(test1) gid=10000(domain users) groups=10000(domain users),10001(biggroup)
Comment 4 Aron Parsons 2015-04-20 16:31:01 UTC 
Created attachment 1016447 [details]
client log
Comment 5 Sumit Bose 2015-04-21 16:45:14 UTC 
I have uploaded a test build to https://sbose.fedorapeople.org/1211830/ . Can you install it on the client and test if it now works as expected?
Comment 6 Aron Parsons 2015-04-22 01:32:05 UTC 
Hi Sumit,
No luck with those packages.  Info below and updated logs for both the server and client attached.  The exop is failing with error 32, no such object.

[root@ipa01 ~]# rpm -q sssd; grep -e default_domain_suffix -e qualified /etc/sssd/sssd.conf; service sssd stop; rm -f /var/lib/sss/{db,mc}/* /var/log/sssd/*; service sssd start; id test1
sssd-1.12.2-58.el7_1.6sb.x86_64
#use_fully_qualified_names = true
default_domain_suffix = example.com
Redirecting to /bin/systemctl stop  sssd.service
Redirecting to /bin/systemctl start  sssd.service
uid=10000(test1) gid=10000(domain users) groups=10000(domain users),730800023(ad_biggroup),10001(biggroup)


[root@client01 ~]# rpm -q sssd; grep -e default_domain_suffix -e qualified /etc/sssd/sssd.conf; service sssd stop; rm -f /var/lib/sss/{db,mc}/* /var/log/sssd/*; service sssd start; id test1; service sssd stop
sssd-1.12.2-58.el7_1.6sb.x86_64
#use_fully_qualified_names = true
#default_domain_suffix = example.com
Redirecting to /bin/systemctl stop  sssd.service
Redirecting to /bin/systemctl start  sssd.service
id: test1: no such user
Redirecting to /bin/systemctl stop  sssd.service
Comment 7 Aron Parsons 2015-04-22 01:32:26 UTC 
Created attachment 1017178 [details]
client sssd log
Comment 8 Aron Parsons 2015-04-22 01:32:52 UTC 
Created attachment 1017179 [details]
server sssd log
Comment 9 Aron Parsons 2015-04-22 01:33:42 UTC 
Created attachment 1017180 [details]
dirsrv access log
Comment 10 Sumit Bose 2015-04-22 11:35:49 UTC 
Can you add the matching sssd_nss logs and full sssd.conf from client and server as well.
Comment 11 Aron Parsons 2015-04-23 00:58:51 UTC 
Created attachment 1017677 [details]
sssd logs
Comment 12 Sumit Bose 2015-04-23 18:28:18 UTC 
Thank you for the logs. On the server the request is processed as requested but processing stopped after biggroup is resolved. Unfortunately I still cannot reproduce this behavior. It would be nice if you can switch on debugging in the directory server as described in http://www.port389.org/docs/389ds/FAQ/faq.html#troubleshooting . The log level needed here is '65536' (Plug-in debugging). Please attach the error log created during the request to this ticket. After that please set the log level back to 0.
Comment 13 Aron Parsons 2015-04-27 00:23:23 UTC 
Created attachment 1019174 [details]
sssd and dirsrv logs
Comment 14 Aron Parsons 2015-04-27 00:31:13 UTC 
Hi Sumit,
I attached new sssd and dirsrv logs.  I have this issue in one real testing environment, this test environment that I'm using to provide these logs, and as of Friday, one production environment, where we needed to go to RHEL 7.1 to address other CVEs.  The workaround of disabling default_domain_suffix works in all environments.

These logs are from a test environment that is as vanilla as you can get: fresh AD 2012 install and fresh RHEL 7.0 installs for the IPA client and server upgraded to RHEL 7.1 for recreating this issue.  I can upload the AD and RHEL VMs to provide to you if you want to poke around with the exact configuration that's exhibiting the issue.
Comment 15 Sumit Bose 2015-04-27 09:48:16 UTC 
Thank you, I think the new logs helped me to track down the issue. I had a patch in my test system which I thought is already in the RHEL packages but apparently is not. Please try the new packages from https://sbose.fedorapeople.org/1211830/.
Comment 16 Aron Parsons 2015-04-28 04:56:26 UTC 
That seems to fix it!

Is there an upstream commit I can pull in to test in my other environments?  We're tracking the 1.12 branch for our RHEL6 and RHEL7 systems until some of the latest fixes (e.g., slow initgroups) land in RHEL7.1 (and eventually RHEL6.7).  I tested the few patches I saw land upstream today that you had authored thinking they might be the ones here in your test packages, but they did not fix it in my test.  I'm hoping you say the patch hasn't landed upstream yet so that I haven't tripped onto another bug! :-)

broken:
[root@ipa01 ~]# rpm -q sssd; grep -e default_domain_suffix -e qualified /etc/sssd/sssd.conf; service sssd stop; rm -f /var/lib/sss/{db,mc}/*; service sssd start; id test1
sssd-1.12.2-58.el7_1.6sb.x86_64
default_domain_suffix = example.com
Redirecting to /bin/systemctl stop  sssd.service
Redirecting to /bin/systemctl start  sssd.service
uid=10000(test1) gid=10000(domain users) groups=10000(domain users),730800023(ad_biggroup),10001(biggroup)

[root@client01 ~]# rpm -q sssd; grep -e default_domain_suffix -e qualified /etc/sssd/sssd.conf; service sssd stop; rm -f /var/lib/sss/{db,mc}/*; service sssd start; id test1
sssd-1.12.2-58.el7_1.6sb.x86_64
default_domain_suffix = example.com
Redirecting to /bin/systemctl stop  sssd.service
Redirecting to /bin/systemctl start  sssd.service
id: test1: no such user


fixed:
[root@ipa01 ~]# rpm -q sssd; grep -e default_domain_suffix -e qualified /etc/sssd/sssd.conf; service sssd stop; rm -f /var/lib/sss/{db,mc}/*; service sssd start; id test1
sssd-1.12.2-58.el7_1.8sb.x86_64
default_domain_suffix = example.com
Redirecting to /bin/systemctl stop  sssd.service
Redirecting to /bin/systemctl start  sssd.service
uid=10000(test1) gid=10000(domain users) groups=10000(domain users),730800023(ad_biggroup.com),10001(biggroup)

[root@client01 ~]# rpm -q sssd; grep -e default_domain_suffix -e qualified /etc/sssd/sssd.conf; service sssd stop; rm -f /var/lib/sss/{db,mc}/*; service sssd start; id test1
sssd-1.12.2-58.el7_1.8sb.x86_64
default_domain_suffix = example.com
Redirecting to /bin/systemctl stop  sssd.service
Redirecting to /bin/systemctl start  sssd.service
uid=10000(test1) gid=10000(domain users) groups=10000(domain users),730800023(ad_biggroup.com),10001(biggroup)
Comment 17 Sumit Bose 2015-04-28 13:17:56 UTC 
The patch I added to the last build is only in git master, not in the 1,12 branch. You can find it at

https://git.fedorahosted.org/cgit/sssd.git/commit/?id=804df4040eb142f82a44c019c7a55b5ce524583c

Additionally it contains the patch from the first build which didn't fixed the issue for you.
Comment 18 Aron Parsons 2015-04-29 03:39:28 UTC 
Hi Sumit,
I got this resolved in my other environments but ran into two other bugs in the process.  One can be recreated on vanilla RHEL7 sssd packages, the other is related to another commit of yours I pulled in.

The first is related to autofs:
https://bugzilla.redhat.com/show_bug.cgi?id=1216285

The other is segfault related to your upstream commit in the sssd-1-12 branch 3453e4734d2f7738034af61edb7d33c0c7095d8a.  I can trigger it by assigning an AD group sudo commands, dropping the cache, and listing the sudo commands for an AD user (sss_cache -E; sudo -U test1 -l).  I've attached the backtrace and a patch for that; no BZ since this patch is not in the RHEL7 packages yet.  I can submit to the upstream devel list if that's more appropriate, but since we already have a dialogue here, I thought I'd throw it in.

I would like to thank you and the team for the work on the AD trust functionality as well.  It's great having good interoperation with AD and not losing the functionality we rely on from a native IPA domain.
Comment 19 Aron Parsons 2015-04-29 03:39:46 UTC 
Created attachment 1019963 [details]
exop-backtrace
Comment 20 Aron Parsons 2015-04-29 03:40:11 UTC 
Created attachment 1019964 [details]
segfault-patch
Comment 21 Jakub Hrozek 2015-04-29 06:58:52 UTC 
(In reply to Aron Parsons from comment #18)
> The other is segfault related to your upstream commit in the sssd-1-12
> branch 3453e4734d2f7738034af61edb7d33c0c7095d8a.  I can trigger it by
> assigning an AD group sudo commands, dropping the cache, and listing the
> sudo commands for an AD user (sss_cache -E; sudo -U test1 -l). 
> I've attached the backtrace and a patch for that; no BZ since this patch is
> not in the RHEL7 packages yet.  I can submit to the upstream devel list if
> that's more appropriate, but since we already have a dialogue here, I
> thought I'd throw it in.

This commit is already present in 6.7 and 7.1 packages. Did you verify it fixes the probem for you?
Comment 22 Sumit Bose 2015-04-29 09:36:30 UTC 
Jakub, I think Aron meant it the other way round, the commit causes the sefault for him and his fix of obviously correct.

Aron, if you don't mind, please send the patch for review to sssd-devel.
Comment 23 Jakub Hrozek 2015-04-29 09:40:04 UTC 
Sorry, I totally missed the patch part..
Comment 24 Jakub Hrozek 2015-04-30 08:52:41 UTC 
Upstream ticket:
https://fedorahosted.org/sssd/ticket/2647
Comment 25 Jakub Hrozek 2015-05-06 08:42:29 UTC 
The last related patch just landed upstream:
    master: 3fe2e555edd3963d72483600e5d9616873afd00a
    sssd-1-12: 226224c91971247f60a86d9c46dd1402f5c29e8a
Comment 27 Sudhir Menon 2015-10-05 09:27:57 UTC 
Verified using RHEL7.2 and Windows 2012 R2.

sssd-1.13.0-36.el7.x86_64
ipa-server-4.2.0-12.el7.x86_64
ipa-server-dns-4.2.0-12.el7.x86_64
ipa-server-trust-ad-4.2.0-12.el7.x86_64

Steps Done to reproduce the issue:-

1. [root@ipa01 ~]# id test1
uid=10030(test1) gid=1902400023(biggroup) groups=1902400023(biggroup)

2. [root@ipa01 ~]# ipa group-add --desc 'external-biggroup' --external external_biggroup
-------------------------------
Added group "external_biggroup"
-------------------------------
  Group name: external_biggroup
  Description: external-biggroup

3. [root@ipa01 ~]# ipa group-add-member --users='' --groups='' --external 'TEST\biggroup' external_biggroup
  Group name: external_biggroup
  Description: external-biggroup
  External member: S-1-5-21-742749997-2996825573-4184801258-6454
-------------------------
Number of members added 1
-------------------------

4. [root@ipa01 ~]# ipa group-add --desc 'ad - biggroup' ad_biggroup
-------------------------
Added group "ad_biggroup"
-------------------------
  Group name: ad_biggroup
  Description: ad - biggroup
  GID: 653800016

5. [root@ipa01 ~]# ipa group-add-member --users='' --groups=external_biggroup ad_biggroup
  Group name: ad_biggroup
  Description: ad - biggroup
  GID: 653800016
  Member groups: external_biggroup
-------------------------
Number of members added 1
-------------------------

6.  With default_domain_suffix not set on IPA Server 

[root@ipa01 ~]# grep default_domain_suffix /etc/sssd/sssd.conf; id test1
uid=10030(test1) gid=1902400023(biggroup) groups=1902400023(biggroup),653800016(ad_biggroup)

[root@ipaclient02 ~]# id test1
uid=10030(test1) gid=1902400023(biggroup) groups=1902400023(biggroup),653800016(ad_biggroup)

7. With default_domain_suffix set on the IPA Server.

[root@ipa01 ~]# grep default_domain_suffix /etc/sssd/sssd.conf; id test1
default_domain_suffix = test.in
uid=10030(test1) gid=1902400023(biggroup) groups=1902400023(biggroup),653800016(ad_biggroup)

[root@ipaclient02 ~]# id test1
uid=10030(test1) gid=1902400023(biggroup) groups=1902400023(biggroup),653800016(ad_biggroup)
Comment 28 errata-xmlrpc 2015-11-19 11:38:03 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://rhn.redhat.com/errata/RHSA-2015-2355.html
Note You need to log in before you can comment on or make changes to this bug.