Hide Forgot
Created attachment 839236 [details] try all attributes when saving an entry Description of problem: When specifying override_gid on sssd.conf, it will not work if the LDAP server does not return a gid attribute when querying the LDAP user information. Version-Release number of selected component (if applicable): 1.9.2-82.10 How reproducible: Always Steps to Reproduce: 1. Use a LDAP server which does not return a gid (e.g. Tivoli Directory Server) 2. Configure sssd.conf with override_gid, say, 1000 with group 1000 being 'mygroup' in /etc/group 3. Query user information 4. As sssd does not get the gid, it will cease to process user info at this time, not saving it, and getent passwd <user> or any other such command will not work And sorry, but I do not have sssd logs containing the problem because it was solved with a patch that jhrozek sent me which, according to him, was a hack/workaround for the time being. The patch is attached on this bug report. Actual results: no getent / id command working Expected results: getend / id would return the user with the given group Additional info: patch which worked around the problem is attached
Also, the bug remains on newer versions of sssd
There are actually several issues to keep in mind here, only one of which is actually resolved by the attached patch. 1) It is asserted that if override_gid is being used, we should not fail to save users that have no gid attribute in their LDAP user entry. This would require us to change the search filters we use for finding user entries if override_gid is in use on the domain (currently we intentionally filter out users missing a GID). 2) The workaround that was offered here was to set 'ldap_group_gid = uidNumber' (the same as the UID, so it could then be safely overridden). However, we have a bug in the attribute processing where it ended up not populating both UID and GID (it stopped at the first match). As a result, the user failed to save to sysdb. This is the issue addressed by the attached patch. The second issue is fairly serious, as there may be other times that we need to save the same attribute in two places (such as GECOS and Full Name, for one example). The first issue will have a viable workaround once the second is addressed, so it is lower priority.
The patch still needs some work (and ideally a unit test), I remember I was able to break LDAP searches under some conditions with the patch. I don't recall the details, but that's the reason the patch wasn't accepted upstream yet. Until now, there had been no bug report, so the patch has had a lower priority :-)
Upstream ticket: https://fedorahosted.org/sssd/ticket/2183
Upstream ticket: https://fedorahosted.org/sssd/ticket/2184
Fixed upstream: master: eed2073f6f7bed7df0327b9fc0f2d410975d5332
Patch is included in upstream sssd >= 1.12 sh$ git tag --contains eed2073f6f7bed7df0327b9fc0f2d410975d5332 sssd-1_12_0 sssd-1_12_1 sssd-1_12_2
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle. Changing version to '22'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22
The problem the original reporter had was fixed for some time. I'm closing as CURRENTRELEASE, please reopen if the issue is still there.