Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
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.
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:
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.
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.
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: