Bug 1211830
| Summary: | external users do not resolve with "default_domain_suffix" set in IPA server sssd.conf | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Aron Parsons <parsonsa> | ||||||||||||||||||
| Component: | sssd | Assignee: | SSSD Maintainers <sssd-maint> | ||||||||||||||||||
| Status: | CLOSED ERRATA | QA Contact: | Kaushik Banerjee <kbanerje> | ||||||||||||||||||
| Severity: | medium | Docs Contact: | |||||||||||||||||||
| Priority: | medium | ||||||||||||||||||||
| Version: | 7.1 | CC: | grajaiya, jgalipea, jhrozek, lslebodn, mkosek, mzidek, nsoman, parsonsa, pbrezina, preichl, rcritten, sbose, sumenon | ||||||||||||||||||
| Target Milestone: | rc | ||||||||||||||||||||
| Target Release: | --- | ||||||||||||||||||||
| Hardware: | x86_64 | ||||||||||||||||||||
| OS: | Linux | ||||||||||||||||||||
| Whiteboard: | |||||||||||||||||||||
| 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.
|
Story Points: | --- | ||||||||||||||||||
| Clone Of: | Environment: | ||||||||||||||||||||
| Last Closed: | 2015-11-19 11:38:03 UTC | Type: | Bug | ||||||||||||||||||
| Regression: | --- | Mount Type: | --- | ||||||||||||||||||
| Documentation: | --- | CRM: | |||||||||||||||||||
| Verified Versions: | Category: | --- | |||||||||||||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||||||||||||
| Embargoed: | |||||||||||||||||||||
| Attachments: |
|
||||||||||||||||||||
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.
(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) Created attachment 1016447 [details]
client log
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? 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
Created attachment 1017178 [details]
client sssd log
Created attachment 1017179 [details]
server sssd log
Created attachment 1017180 [details]
dirsrv access log
Can you add the matching sssd_nss logs and full sssd.conf from client and server as well. Created attachment 1017677 [details]
sssd logs
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. Created attachment 1019174 [details]
sssd and dirsrv logs
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. 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/. 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)
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. 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. Created attachment 1019963 [details]
exop-backtrace
Created attachment 1019964 [details]
segfault-patch
(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? 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. Sorry, I totally missed the patch part.. Upstream ticket: https://fedorahosted.org/sssd/ticket/2647 The last related patch just landed upstream:
master: 3fe2e555edd3963d72483600e5d9616873afd00a
sssd-1-12: 226224c91971247f60a86d9c46dd1402f5c29e8a
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) 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 |
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.