Bug 1417170 - SSSD not resolving group membership on logon via LDAP/AD
Summary: SSSD not resolving group membership on logon via LDAP/AD
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: sssd
Version: 6.8
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: rc
: ---
Assignee: Pavel Březina
QA Contact: sssd-qe
URL:
Whiteboard:
Depends On:
Blocks: 1461138
TreeView+ depends on / blocked
 
Reported: 2017-01-27 12:08 UTC by Andrey Bondarenko
Modified: 2020-12-14 08:03 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-10-26 08:14:06 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Andrey Bondarenko 2017-01-27 12:08:31 UTC
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):

        sssd-1.13.3-22.el6_8.4.x86_64
        sudo-1.8.6p3-24.el6.x86_64
        glibc-2.12-1.192.el6.x86_64
        glibc-2.12-1.192.el6.i686

How reproducible:

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.

Actual results:
 sudo not working

Expected results:
 sudo working

Comment 9 Jakub Hrozek 2017-02-20 08:48:08 UTC
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.

Comment 10 mcalnd 2017-03-10 15:21:10 UTC
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

Comment 11 Andrey Bondarenko 2017-04-24 12:52:57 UTC
Hello,

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.

Andrey Bondarenko


Note You need to log in before you can comment on or make changes to this bug.