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: |
|
Description
Aron Parsons
2015-04-15 02:44:02 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.
(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 |