Bug 1283477 - Improve sssd nss multiple groups message
Improve sssd nss multiple groups message
Status: CLOSED WORKSFORME
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: sssd (Show other bugs)
7.1
All Linux
unspecified Severity high
: rc
: ---
Assigned To: Lukas Slebodnik
Namita Soman
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-11-19 00:18 EST by Paul Wayper
Modified: 2016-01-07 03:40 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-01-07 03:40:37 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 Paul Wayper 2015-11-19 00:18:22 EST
Description of problem:

Several functions in the src/responder/nss/nsssrv_cmd.c code detect if they get more than one result and return an error if they were expecting only one.  The code follows this pattern:

        if (dctx->res->count > 1) {
            DEBUG(SSSDBG_FATAL_FAILURE,
                  "getpwuid call returned more than one result !?!\n");
            sss_log(SSS_LOG_ERR,
                    "More users have the same UID [%"PRIu32"] in directory "
                    "server. SSSD will not work correctly.\n", cmdctx->id);
            ret = ENOENT;
            goto done;
        }

In the case of user names it is easy to find the user by name and investigate their properties.  However, in the case of UIDs and GIDs, this is harder to diagnose.

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

sssd-1.12.4-47.el6.x86_64
sssd-ad-1.12.4-47.el6.x86_64
sssd-client-1.12.4-47.el6.x86_64
sssd-common-1.12.4-47.el6.x86_64
sssd-common-pac-1.12.4-47.el6.x86_64
sssd-ipa-1.12.4-47.el6.x86_64
sssd-krb5-1.12.4-47.el6.x86_64
sssd-krb5-common-1.12.4-47.el6.x86_64
sssd-ldap-1.12.4-47.el6.x86_64
sssd-proxy-1.12.4-47.el6.x86_64
sssd-tools-1.12.4-47.el6.x86_64

How reproducible:

Quite reliable

Steps to Reproduce:
1. Do something that causes two groups to map to the same ID.
2. getent group onegroup

Actual results:

3. Get message "More groups have the same GID [1234567890] in directory server. SSSD will not work correctly."

Expected results:

3. Get something like:

"Groups 1592648730, 1357924680 and 1472583690 map to the same GID 1234567890 in directory server.  SSSD will not work correctly."

Additional info:
Comment 2 Jakub Hrozek 2015-11-19 03:38:37 EST
This error means that there are two (or more) objects in the cache with the same numerical ID. This can either be a reflection of server misconfiguration in case the admin assigns the IDs and assigns the same one to two objects.

But neither of the two cases linked uses manual POSIX IDs, both use algorithmical ID mapping. There SSSD derives IDs from Windows SIDs on its own, so conflicts shouldn't happen.

btw I don't think this is a mapping conflict per se, but a failure to rename a group correctly. What we do during initgroups() with ID mapping schema is that we derive group GIDs from Window SIDs and store group "stubs" with just the SID and the GID (no name) to cache. Later, when the groups are resolved into full objects with name etc we should remove the stub object and insert a full object instead -- looks like we have an error there.

In the e-mail conversation earlier you indicated the bug was reproducable. Could you please attach debug logs with a high debug level to this bug? If there are some steps that help reproduce the bug (like login or running id), then please also run "date" when running those commands so that we can match the debug logs with the commands.

See https://fedorahosted.org/sssd/wiki/Reporting_sssd_bugs#Includenecessarydebuggingdata and https://fedorahosted.org/sssd/wiki/Troubleshooting for some more details.
Comment 3 Lukas Slebodnik 2015-11-19 03:49:37 EST
I would suspect colliding GIDs in LDAP server if you could see messages in syslog (or sssd_nss.log)

If you can see such messages only in sssd domain log file then it can be the same case as Jakub described.

I agree with Jakub that we need to see log files + sssd.conf. The LDIF of problematic groups from LDAP server (AD) might be useful as well.
Comment 4 Jakub Hrozek 2015-11-19 03:54:43 EST
Also ldb cache dump might be useful to have:
ldbsearch -H /var/lib/sss/db/cache_$ > dump.txt
Comment 13 Lukas Slebodnik 2015-12-10 09:59:21 EST
Sumit had a good point.
We changed the default attribute for group name in sssd-1.13.0
https://git.fedorahosted.org/cgit/sssd.git/commit/?id=adb148603344a42d6edffdda0786a10af715dacb
http://file.brq.redhat.com/lslebodn/SRPMS/freeipa-4.2.3.201512101352GIT64928e9-0.fc23.src.rpm

So if they have different string in attribute "name" and "sAMAccountName"
it might solve the issue with two groups with the same name but different DN.

Could they test with sssd on rhel7.2?
or could they test with following line in domain section (sssd.conf)?
ldap_group_name = sAMAccountName
Comment 15 Jakub Hrozek 2015-12-16 08:22:31 EST
ping, any news?

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