Bug 1475985 - Group renaming issue when "id_provider = ldap" is set.
Group renaming issue when "id_provider = ldap" is set.
Status: CLOSED DUPLICATE of bug 1401241
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: sssd (Show other bugs)
6.8
Unspecified Linux
unspecified Severity high
: rc
: ---
Assigned To: SSSD Maintainers
sssd-qe
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2017-07-27 13:21 EDT by fnie
Modified: 2017-11-13 16:27 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-11-13 16:27:59 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description fnie 2017-07-27 13:21:26 EDT
Description of problem:

sssd cache have invalid group, which already been deleted long time, but still in the cache, have the gid number: 1404.

and there is new group are using the gid again 1404. on the ldap side the gid number is uniqe, but in the sssd cache there are two entry with same gid, that cause id command can not get the group name.


id: cannot find name for group ID 1404

dump the cache:
# record 571
dn: name=xxxx1
createTimestamp: 1500531223
gidNumber: 1404
objectClass: group
isPosix: TRUE
...

# record 7521
dn: name=xxxx2
createTimestamp: 1495122412
gidNumber: 1404
objectClass: group
isPosix: TRUE

group name is different.xxxx2 is the old group, and after i try getent group xxxx2, then the old group is gone, i think the sssd found it's not exist in ldap, so remove it.

my quesiton, why this remove dose not happen when the ldap group remove in ldap server side.

sssd.conf:

[sssd]
config_file_version = 2
reconnection_retries = 3

# If a back end is particularly slow you can raise this timeout here
sbus_timeout = 30
services = nss, pam
domains = AD

[nss]
filter_groups = root
filter_users = root
reconnection_retries = 3

[pam]
reconnection_retries = 3

# Example LDAP domain where the LDAP server is an Active Directory server.

[domain/AD]
description = LDAP domain with AD server
enumerate = false

debug_level = 7

ldap_id_use_start_tls = False
cache_credentials = True
id_provider = ldap
auth_provider = krb5
chpass_provider = krb5
ldap_schema = rfc2307bis
ldap_force_upper_case_realm = True
ldap_user_object_class = person
ldap_group_object_class = group
ldap_user_gecos = gecos
ldap_user_home_directory = unixHomeDirectory
ldap_uri =  ldap://xxxxx
ldap_search_base = dc=apd,dc=ebay,dc=com
ldap_default_bind_dn = xxxxx
#ldap_group_search_base = ou=Group,dc=ebay,dc=com
ldap_group_search_base = OU=Groups,OU=Data,xxxx
ldap_default_authtok_type = password
ldap_default_authtok = xxxx
ldap_referrals = false
krb5_realm = xxx
krb5_kpasswd = xxxxx
krb5_kdcip = xxxx
ldap_user_name = sAMAccountName
ldap_user_uid_number = uidNumber
ldap_user_gid_number = gidNumber
ldap_user_search_filter = (&(uidNumber=*)(gidNumber=*))
ldap_group_search_filter = (objectClass=group)
#ldap_group_name = name
#ldap_group_member = member



Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:
Comment 2 fnie 2017-07-27 13:23:23 EDT
sssd version: 1.13.3-56.el6
Comment 3 Jakub Hrozek 2017-07-27 14:11:36 EDT
Well, if removing the cache works, then I guess it's https://pagure.io/SSSD/sssd/issue/3282
Comment 4 Jakub Hrozek 2017-07-27 14:13:09 EDT
btw there are candidate patches for #3282, if you're interested in testing them to see if they fix your issue, then I can build you a test package. But since this bug seems to have a workaround, it's not likely we would fix the bug in RHEL-6 (for sure not without a support case)
Comment 5 fnie 2017-07-31 12:17:59 EDT
Hi Hrozek,

are you say the patch is not for centos6 ?

so we have to upgrade to 7? or is there any workaround we can skip it.
Comment 6 Lukas Slebodnik 2017-07-31 12:59:51 EDT
(In reply to fnie from comment #5)
> Hi Hrozek,
> 
> are you say the patch is not for centos6 ?
> 
> so we have to upgrade to 7? or is there any workaround we can skip it.

There are two possible explanation of two different groups with the same GID in sssd cache.

A) there are two groups in LDAP with the same GID
   => such configuration is not supported by SSSD due to security reasons.
B) groupA was renamed to groupB LDAP
   => in this case removing sssd cache is sufficient workaround. 
      (sss_cache will not help) 
      and issue is tracked in upstream ticket https://pagure.io/SSSD/sssd/issue/3282
Comment 7 fnie 2017-07-31 13:02:40 EDT
it's the B, 

there is an old group a, then we drop it, create new group b, but it's using the same gid, our program on check if the gid is used or not, if its ok, then it will use.

so it's same situation as rename.
Comment 8 Lukas Slebodnik 2017-07-31 13:12:23 EDT
(In reply to fnie from comment #7)
> it's the B, 
> 
> there is an old group a, then we drop it, create new group b, but it's using
> the same gid, our program on check if the gid is used or not, if its ok,
> then it will use.
> 
> so it's same situation as rename.

In that case patch for ticket https://pagure.io/SSSD/sssd/issue/3282 would help but rhel6 is in late phase of lifecycle. So it's not very likely we would fix the bug in RHEL-6 (for sure not without a support case which requires RHEL subscription). But from upstream POV it would not be a problem to fix it.

I hope it is clear now.

But if you do not rename group very often then clearing sssd cache + restarting sssd might be reasonable/feasible workaround.
Comment 9 Jakub Hrozek 2017-08-14 08:59:20 EDT
Upstream ticket:
https://pagure.io/SSSD/sssd/issue/3282
Comment 10 Jakub Hrozek 2017-11-13 16:27:59 EST

*** This bug has been marked as a duplicate of bug 1401241 ***

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