#3282 Group renaming issue when "id_provider = ldap" is set.
Closed: duplicate 6 years ago Opened 7 years ago by jhrozek.

Ticket was cloned from Red Hat Bugzilla (product Red Hat Enterprise Linux 6): Bug 1401241

Please note that this Bug is private and may not be accessible as it contains confidential Red Hat customer information.

Description of problem:

Group renaming issue when "id_provider = ldap" is set.

In ldap/Active Directory, if a group is renamed but retains the same gidNumber,
then in ldap client after cache expiry only the gidNumber is displayed for the
user, the new groupname is not displayed.


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

sssd-1.9.2-129  and also 1.13.3


How reproducible:

Always


Steps to Reproduce from latest case:

1) Create a test AD group (for example unixtest99) and test with the groups
command:

   [user@server ~]$ groups
   Domain Linux Users Marketing unixtest99


2) Change the name of the group (from unixtest99 to unixtest04)


3) After sometime, check the groups again and see that it is not resolving to
the new name:

   [user@server ~]$ groups
   Domain Linux Users Marketing groups: cannot find name for group ID 10040
   10040


In short, if there are any changes to an AD group name, the customer has to
refresh the sssd cache, which may not scale well on a large system.


Actual results:
group name isn't returned

Expected results:
new group name is returned

Fields changed

blockedby: =>
blocking: =>
changelog: =>
coverity: =>
design: =>
design_review: => 0
feature_milestone: =>
fedora_test_page: =>
mark: no => 0
owner: somebody => fidencio
patch: => 1
review: True => 0
selected: =>
testsupdated: => 0

Fields changed

milestone: NEEDS_TRIAGE => SSSD 1.14.3

Metadata Update from @jhrozek:
- Issue assigned to fidencio
- Issue set to the milestone: SSSD 1.14.3

7 years ago

Metadata Update from @jhrozek:
- Custom field design_review reset (from 0)
- Custom field mark reset (from 0)
- Custom field patch adjusted to on (was: 1)
- Custom field review reset (from 0)
- Custom field sensitive reset (from 0)
- Custom field testsupdated reset (from 0)
- Issue close_status updated to: None
- Issue set to the milestone: SSSD 1.15.4 (was: SSSD 1.14.3)
- Issue tagged with: PR

6 years ago

This bug is dup of https://pagure.io/SSSD/sssd/issue/3282 and I'm closing this one based on this.

Metadata Update from @fidencio:
- Custom field design_review reset (from false)
- Custom field mark reset (from false)
- Custom field review reset (from false)
- Custom field sensitive reset (from false)
- Custom field testsupdated reset (from false)

6 years ago

Metadata Update from @fidencio:
- Custom field design_review reset (from false)
- Custom field mark reset (from false)
- Custom field review reset (from false)
- Custom field sensitive reset (from false)
- Custom field testsupdated reset (from false)
- Issue close_status updated to: duplicate
- Issue status updated to: Closed (was: Open)

6 years ago

Thorsten pointed me that I closed this bug as duplicated of itself. /o.

When I closed it, I meant it's a duplicate of https://pagure.io/SSSD/sssd/issue/2653

Metadata Update from @fidencio:
- Custom field design_review reset (from false)
- Custom field mark reset (from false)
- Custom field review reset (from false)
- Custom field sensitive reset (from false)
- Custom field testsupdated reset (from false)

6 years ago

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/4315

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Login to comment on this ticket.

Metadata