Description of problem:
SSSD not resolving group membership on logon via LDAP/AD unless id is runed prior to it. Then it works for 5 minutes.
Version-Release number of selected component (if applicable):
When logging onto WORKING.host using Active Directory username and password, sudo could be instantly used command as AD group membership is configured and added into the sudoers file
When logging into NONWORKING.host however using the same credentials, any attempt to run SUDO fails. To make it work id command have to be issued first and then the SUDO command completes. But only for about 5 minutes. If tried the SUDO command again after 5 minutes, it will fail. Then have to issue the ID command again.
The difference is the version, RHEL 6.5 works and if updated to 6.8 - not.
sudo not working
As a short-term fix, I would ask if disabling tokengroups with "ldap_use_tokengroups=False" helps mitigate the issue. Please see the discussion in https://bugzilla.redhat.com/show_bug.cgi?id=1372440#c20 and onwards.
Hi - an update on this. I have deployed SSSD across another set of servers. The kernel is still registered at 6.5, but a mix of hosts, depending on when and how they where patched, are on different versions of SSSD
The deployment of SSSD to these Production servers all use the same running SSSD.CONF file (as previously supplied).
Of note: the working servers have:
python-sssdconfig.noarch 1.12.4-47.el6_7.8 @rhel-6-server-rpms
sssd.x86_64 1.12.4-47.el6_7.8 @rhel-6-server-rpms
sssd-ad.x86_64 1.12.4-47.el6_7.8 @rhel-6-server-rpms
sssd-client.x86_64 1.12.4-47.el6_7.8 @rhel-6-server-rpms
sssd-common.x86_64 1.12.4-47.el6_7.8 @rhel-6-server-rpms
sssd-common-pac.x86_64 1.12.4-47.el6_7.8 @rhel-6-server-rpms
sssd-ipa.x86_64 1.12.4-47.el6_7.8 @rhel-6-server-rpms
sssd-krb5.x86_64 1.12.4-47.el6_7.8 @rhel-6-server-rpms
sssd-krb5-common.x86_64 1.12.4-47.el6_7.8 @rhel-6-server-rpms
sssd-ldap.x86_64 1.12.4-47.el6_7.8 @rhel-6-server-rpms
sssd-proxy.x86_64 1.12.4-47.el6_7.8 @rhel-6-server-rpms
The non-working servers have:
python-sssdconfig.noarch 1.13.3-22.el6_8.4 @rhel-6-server-rpms
sssd.x86_64 1.13.3-22.el6_8.4 @rhel-6-server-rpms
sssd-ad.x86_64 1.13.3-22.el6_8.4 @rhel-6-server-rpms
sssd-client.x86_64 1.13.3-22.el6_8.4 @rhel-6-server-rpms
sssd-common.x86_64 1.13.3-22.el6_8.4 @rhel-6-server-rpms
sssd-common-pac.x86_64 1.13.3-22.el6_8.4 @rhel-6-server-rpms
sssd-ipa.x86_64 1.13.3-22.el6_8.4 @rhel-6-server-rpms
sssd-krb5.x86_64 1.13.3-22.el6_8.4 @rhel-6-server-rpms
sssd-krb5-common.x86_64 1.13.3-22.el6_8.4 @rhel-6-server-rpms
sssd-ldap.x86_64 1.13.3-22.el6_8.4 @rhel-6-server-rpms
sssd-proxy.x86_64 1.13.3-22.el6_8.4 @rhel-6-server-rpms
This information has been derived from yum list installed and grep sssd
I have tested this in a virtual environment and can confirm that between 1.12.4-47.el6_7.8 and 1.13.3-22.el6_8.4 it broke.
I checked the Bugzilla and tried out the recommendation for "ldap_use_tokengroups=False", which I assumed I did it correctly. I don't have the required access to read the linked Bugzilla on that comment
Thank you for the update, but it's not clear if "ldap_use_tokengroups=False" helped? The bug is actually related to sudo which relies on the certain behavior of the sssd that might not happen due to the sssd optimizations. For the RHEL 6 "ldap_use_tokengroups=False" is a workaround.
It's https://pagure.io/SSSD/sssd/issue/2838, but it's not backportable to the 6.x, it's too invasive. But it's fixed in the RHEL 7.