Bug 1369118

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
uid=558000500(administrator) gid=558000500(administrator) groups=558000500(administrator),558000520(group policy creator owners),558000512(domain admins),558000519(enterprise admins),558000518(schema admins),558000513(domain users)


===Before commenting the domain/shadowutils section===
[root@client sssd]# id administrator
uid=558000500(administrator) gid=558000500(administrator) groups=558000500(administrator)

===After commenting the domain/shadowutils section===
[root@client sssd]# id administrator
uid=558000500(administrator) gid=558000500(administrator) groups=558000500(administrator),558000520(group policy creator owners),558000512(domain admins),558000519(enterprise admins),558000518(schema admins),558000513(domain users)

(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
> uid=558000500(administrator) gid=558000500(administrator)
> groups=558000500(administrator),558000520(group policy creator
> owners),558000512(domain admins),558000519(enterprise
> admins),558000518(schema admins),558000513(domain users)
> 
> 
> ===Before commenting the domain/shadowutils section===
> [root@client sssd]# id administrator
> uid=558000500(administrator) gid=558000500(administrator)
> groups=558000500(administrator)
> 
> ===After commenting the domain/shadowutils section===
> [root@client sssd]# id administrator
> uid=558000500(administrator) gid=558000500(administrator)
> groups=558000500(administrator),558000520(group policy creator
> owners),558000512(domain admins),558000519(enterprise
> admins),558000518(schema admins),558000513(domain users)

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: 
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