Hide Forgot
Description of problem: We changed one of the groups name in MSAD that was defined as Unix group from uppercase to lowercase. After that we noticed problems with some of the services. In sssd_nss.log we got error messages: (Fri Oct 14 10:03:31 2011) [sssd[nss]] [nss_cmd_getgrgid_search] (0): getgrgid call returned more than one result !?! Problems: 1. Checking groups in domain resulted in this: [root@SERVERNAME db]# getent group |grep -i gr GROUPGROUP:*:10069:username groupgroup:*:10069:username 2. Cache was not updated correctly even after we removed group from Domain and added it again. [root@SERVERNAME db]# getent group |grep -i gr GROUPGROUP:*:10069:username groupgroup:*:10113:username We got expected result only after removing cache from /var/lib/sss/db directory. Resetting service didn't help. [root@SERVERNAME db]# getent group |grep -i gr groupgroup:*:10113:username 3. What is the configuration parameter responsible for cache refresh ? I would like groups / users and memberships to be updated asap. Why if MSAD is case insensitive it is important for SSSD what case group/user has ?? Version-Release number of selected component (if applicable): sssd-client-1.5.1-34.el6_1.3.x86_64 sssd-1.5.1-34.el6_1.3.x86_64
The reason that SSSD behaves in a case-sensitive manner because this is mandated by the POSIX specification. All glibc interfaces for users and groups are case-sensitive, and therefore we must be also. We have an open ticket to behave better in environments like AD which are case-insensitive: https://fedorahosted.org/sssd/ticket/890 The idea here will be to force all identifiers to lower-case on the client machine, regardless of their case on the server. You *have* identified a rather odd bug in the getgrgid() code though. If you were looking up a group directly by GID, it should have completely replaced the old entry in the cache.
Upstream ticket: https://fedorahosted.org/sssd/ticket/1040
(In reply to comment #2) What do you mean? > If you were looking up a group directly by GID, it should have completely > replaced the old entry in the cache. Is there any way to force cache entry to be replaced during next lookup involving user / group that changed in domain?
Sorry, I phrased that poorly. There's a bug in our code in that it only checks whether the current name already exists in our cache. It doesn't check for entries with the same ID. I've opened ticket 1040 upstream to fix this.
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: Cause: when we were adding new group to SSSD cache, we weren't checking if another group with the same GID was already in the database Consequence: if another group with the same GID already existed in the cache when we were trying to add a new one, both groups would continue to exist in the cache which would be obviously problematic if the original no longer existed on the server Fix: when adding new group to the cache, delete any group with the same id that is already in the cache Result: only one group with one GID exists in the database. Therefore multiple groups won't be returned to client in case a group was renamed
Verified in sssd-1.8.0-25 Steps to verify: 1. Add a group USER11_GRP1 2. Configure sssd with enumerate=true and check the enumerated result. # getent group | grep -i user11_grp1 USER11_GRP1:*:11039:user11 3. Rename the group to lowercase i.e. user11_grp1 4. After the next enumeration refresh, check the result again # getent group | grep -i user11_grp1 user11_grp1:*:11039:user11
Retested with sssd-1.8.0-27. With uppercase groupname: # getent group | grep -i user11_grp1 USER11_GRP1:*:11039:user11 After renaming to lowercased name: # getent group | grep -i user11_grp1 user11_grp1:*:11039:user11
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2012-0747.html