Red Hat Bugzilla – Bug 1369118
Don't enable the default shadowtils domain in RHEL
Last modified: 2016-11-04 03:20:46 EDT
Description of problem: ipa-client-install add [domain/shadowutils] in sssd.conf file Version-Release number of selected component (if applicable): sssd-1.14.0-27.el7.x86_64 How reproducible: Always Steps to Reproduce: 1. ipa-client-install 2. Check the /etc/sssd/sssd.conf file Actual results: There is [domain/shadowutils] section added apart from the actual IPA domain to which the client is connected. [root@client ~]# cat /etc/sssd/sssd.conf [domain/redlabs.qe] cache_credentials = True krb5_store_password_if_offline = True ipa_domain = redlabs.qe id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = client.redlabs.qe chpass_provider = ipa ipa_server = _srv_, replica.redlabs.qe ldap_tls_cacert = /etc/ipa/ca.crt [sssd] config_file_version = 2 services = nss, sudo, pam, ssh domains = shadowutils, redlabs.qe [nss] [pam] [domain/shadowutils] id_provider = proxy proxy_lib_name = files auth_provider = proxy proxy_pam_target = sssd-shadowutils proxy_fast_alias = True [ssh] [sudo] Expected results: Not sure if we should have domain/shadowutils section apart from ipa domain section Additional info:
Jakub, Will this also take care of not creating timestamps_shadowutils.ldb file created in /var/lib/sss/db/ directory.
The idea is not ship the shadowutils domain at all in RHEL, so, yes.
Yes we should be removing this as the fix for the issue. Just wanted to share one observation. sss was present in nsswitch.conf file against initgroups in ipa-client. Only after commenting out the below in sssd.conf, found that the id command displayed the proper output i.e the one similar on ipa-server for trusted user. This clearly indicates that the existence of the below section in sssd.conf file can corrupt the output of id command as well. However i believe this is expected because there are two domain sections to be looked upon. #[domain/shadowutils] #id_provider = proxy #proxy_lib_name = files # #auth_provider = proxy #proxy_pam_target = sssd-shadowutils #proxy_fast_alias = True ===id output on IPA server=== [root@ipaserver sssd]# id administrator@pne.qe uid=558000500(administrator@pne.qe) gid=558000500(administrator@pne.qe) groups=558000500(administrator@pne.qe),558000520(group policy creator owners@pne.qe),558000512(domain admins@pne.qe),558000519(enterprise admins@pne.qe),558000518(schema admins@pne.qe),558000513(domain users@pne.qe) ===Before commenting the domain/shadowutils section=== [root@client sssd]# id administrator@pne.qe uid=558000500(administrator@pne.qe) gid=558000500(administrator@pne.qe) groups=558000500(administrator@pne.qe) ===After commenting the domain/shadowutils section=== [root@client sssd]# id administrator@pne.qe uid=558000500(administrator@pne.qe) gid=558000500(administrator@pne.qe) groups=558000500(administrator@pne.qe),558000520(group policy creator owners@pne.qe),558000512(domain admins@pne.qe),558000519(enterprise admins@pne.qe),558000518(schema admins@pne.qe),558000513(domain users@pne.qe)
(In reply to Sudhir Menon from comment #4) > Yes we should be removing this as the fix for the issue. > > Just wanted to share one observation. > sss was present in nsswitch.conf file against initgroups in ipa-client. > Only after commenting out the below in sssd.conf, found that the id command > displayed the proper output i.e the one similar on ipa-server for trusted > user. > > This clearly indicates that the existence of the below section in sssd.conf > file can corrupt the output of id command as well. > > However i believe this is expected because there are two domain sections to > be looked upon. > > #[domain/shadowutils] > #id_provider = proxy > #proxy_lib_name = files > # > #auth_provider = proxy > #proxy_pam_target = sssd-shadowutils > #proxy_fast_alias = True > > ===id output on IPA server=== > [root@ipaserver sssd]# id administrator@pne.qe > uid=558000500(administrator@pne.qe) gid=558000500(administrator@pne.qe) > groups=558000500(administrator@pne.qe),558000520(group policy creator > owners@pne.qe),558000512(domain admins@pne.qe),558000519(enterprise > admins@pne.qe),558000518(schema admins@pne.qe),558000513(domain users@pne.qe) > > > ===Before commenting the domain/shadowutils section=== > [root@client sssd]# id administrator@pne.qe > uid=558000500(administrator@pne.qe) gid=558000500(administrator@pne.qe) > groups=558000500(administrator@pne.qe) > > ===After commenting the domain/shadowutils section=== > [root@client sssd]# id administrator@pne.qe > uid=558000500(administrator@pne.qe) gid=558000500(administrator@pne.qe) > groups=558000500(administrator@pne.qe),558000520(group policy creator > owners@pne.qe),558000512(domain admins@pne.qe),558000519(enterprise > admins@pne.qe),558000518(schema admins@pne.qe),558000513(domain users@pne.qe) The domain shadowutils should not cause such behaviour. That sound to me like a bug in sssd that it cannot handle initgroups properly in multi domain setup. IMHO, you would get right results after following change in sssd.conf -domains = shadowutils, redlabs.qe +domains = redlabs.qe, shadowutils
Sudhir, could you confirm ?
(In reply to Sudhir Menon from comment #4) > Yes we should be removing this as the fix for the issue. > > Just wanted to share one observation. > sss was present in nsswitch.conf file against initgroups in ipa-client. > Only after commenting out the below in sssd.conf, found that the id command > displayed the proper output i.e the one similar on ipa-server for trusted > user. > > This clearly indicates that the existence of the below section in sssd.conf > file can corrupt the output of id command as well. Hi, I wanted to work on this bugzilla and I don't have a problem with removing this functionality in RHEL-7.3. But I can't reproduce the problem you mention where the presence of the additional domain changes the functionality. Could you please set me up a system which reproduces the bug so I can take a look what the problem is exactly? Thank you!
Lukas, Tried what you have mentioned in comment 6, but unfortunately id command doesn't display same output on client. Jakub, Provided the system details on email.
BTW, this bug should not happen with SELinux in enforcing mode. Because sssd would not be allowed to copy default configuration file /usr/lib64/sssd/conf/sssd.conf into /etc/sssd/sssd.conf
(In reply to Jakub Hrozek from comment #8) > (In reply to Sudhir Menon from comment #4) > > Yes we should be removing this as the fix for the issue. > > > > Just wanted to share one observation. > > sss was present in nsswitch.conf file against initgroups in ipa-client. > > Only after commenting out the below in sssd.conf, found that the id command > > displayed the proper output i.e the one similar on ipa-server for trusted > > user. > > > > This clearly indicates that the existence of the below section in sssd.conf > > file can corrupt the output of id command as well. > > Hi, > > I wanted to work on this bugzilla and I don't have a problem with removing > this functionality in RHEL-7.3. But I can't reproduce the problem you > mention where the presence of the additional domain changes the > functionality. > > Could you please set me up a system which reproduces the bug so I can take a > look what the problem is exactly? > > Thank you! Even though this feature was revered in downstream. I would still like to analyse it. Could you please set me up a system which reproduces the bug ?
(In reply to Lukas Slebodnik from comment #14) > Even though this feature was revered in downstream. I would still like to > analyse it. Could you please set me up a system which reproduces the bug ? Feel free to check again, but to me it looked like the problem was in the nsswitch.conf again: 15:32 < jhrozek> smenon: ping, I only restarted ipa on the server to pick up nsswitch.conf changes and now everything works even with the shadowutils domain. Can you please take a look again if I'm not overlooki ng some change? 15:33 < smenon> jhrozek: sure 15:33 < jhrozek> smenon: I still think it makes sense to remove the shadowutils stuff from RHEL, but I just want to make sure I'm not missing another bug 15:33 < smenon> jhrozek: ok 15:34 < smenon> jhrozek: looks good to me as ipa-client is giving correct output as server 15:35 < smenon> jhrozek: but the question remains why would someone restart ipa service for this to work ? 15:35 < smenon> jhrozek: this should be pickedup instantly like it was before without multidomain 15:45 < jhrozek> smenon: that's a different issue, I suspect it has again something to do with the nsswitch.conf authconfig bug 15:45 < jhrozek> smenon: because I wasn't seeing initgroups reaching SSSD from the IPA extdom plugin at all and nsswitch.conf is only read on application startup 15:46 < smenon> jhrozek: ok
Lukas, The issue is no more relevant because multidomain is now removed from the sssd config file. Tested on RHEL7.3 using sssd-client-1.14.0-38.el7.x86_64 sssd-ipa-1.14.0-38.el7.x86_64 sssd-proxy-1.14.0-38.el7.x86_64 sssd-common-1.14.0-38.el7.x86_64 sssd-common-pac-1.14.0-38.el7.x86_64 sssd-ad-1.14.0-38.el7.x86_64 sssd-krb5-1.14.0-38.el7.x86_64 python-sssdconfig-1.14.0-38.el7.noarch sssd-krb5-common-1.14.0-38.el7.x86_64 sssd-ldap-1.14.0-38.el7.x86_64 sssd-1.14.0-38.el7.x86_64 [root@client conf.d]# ipa-client-install WARNING: ntpd time&date synchronization service will not be configured as conflicting service (chronyd) is enabled Use --force-ntpd option to disable it and force configuration of ntpd Discovery was successful! Client hostname: client.testrelm.test Realm: TESTRELM.TEST DNS Domain: testrelm.test IPA Server: master.testrelm.test BaseDN: dc=testrelm,dc=test Continue to configure the system with these values? [no]: yes Skipping synchronizing time with NTP server. User authorized to enroll computers: admin Password for admin@TESTRELM.TEST: Successfully retrieved CA cert Subject: CN=Certificate Authority,O=TESTRELM.TEST Issuer: CN=Certificate Authority,O=TESTRELM.TEST Valid From: Wed Sep 14 10:31:15 2016 UTC Valid Until: Sun Sep 14 10:31:15 2036 UTC Enrolled in IPA realm TESTRELM.TEST Created /etc/ipa/default.conf New SSSD config will be created Configured sudoers in /etc/nsswitch.conf Configured /etc/sssd/sssd.conf Configured /etc/krb5.conf for IPA realm TESTRELM.TEST trying https://master.testrelm.test/ipa/json Forwarding 'ping' to json server 'https://master.testrelm.test/ipa/json' Forwarding 'ca_is_enabled' to json server 'https://master.testrelm.test/ipa/json' Systemwide CA database updated. Adding SSH public key from /etc/ssh/ssh_host_rsa_key.pub Adding SSH public key from /etc/ssh/ssh_host_ecdsa_key.pub Adding SSH public key from /etc/ssh/ssh_host_ed25519_key.pub Forwarding 'host_mod' to json server 'https://master.testrelm.test/ipa/json' SSSD enabled Configured /etc/openldap/ldap.conf Configured /etc/ssh/ssh_config Configured /etc/ssh/sshd_config Configuring testrelm.test as NIS domain. Client configuration complete. [root@client conf.d]# cat /etc/sssd/sssd.conf [domain/testrelm.test] cache_credentials = True krb5_store_password_if_offline = True ipa_domain = testrelm.test id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = client.testrelm.test chpass_provider = ipa ipa_server = _srv_, master.testrelm.test ldap_tls_cacert = /etc/ipa/ca.crt [sssd] services = nss, sudo, pam, ssh domains = testrelm.test [nss] homedir_substring = /home [pam] [sudo] [autofs] [ssh] [pac] [ifp]
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/RHEA-2016-2476.html