RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1475985 - Group renaming issue when "id_provider = ldap" is set.
Summary: Group renaming issue when "id_provider = ldap" is set.
Keywords:
Status: CLOSED DUPLICATE of bug 1401241
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: sssd
Version: 6.8
Hardware: Unspecified
OS: Linux
unspecified
high
Target Milestone: rc
: ---
Assignee: SSSD Maintainers
QA Contact: sssd-qe
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-07-27 17:21 UTC by fnie
Modified: 2020-05-02 18:36 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-11-13 21:27:59 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github SSSD sssd issues 4315 0 None closed Group renaming issue when "id_provider = ldap" is set. 2021-01-27 07:22:57 UTC

Description fnie 2017-07-27 17:21:26 UTC
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 17:23:23 UTC
sssd version: 1.13.3-56.el6

Comment 3 Jakub Hrozek 2017-07-27 18:11:36 UTC
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 18:13:09 UTC
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 16:17:59 UTC
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 16:59:51 UTC
(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 17:02:40 UTC
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 17:12:23 UTC
(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 12:59:20 UTC
Upstream ticket:
https://pagure.io/SSSD/sssd/issue/3282

Comment 10 Jakub Hrozek 2017-11-13 21:27:59 UTC

*** 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.