Learn more about these different git repos.
Other Git URLs
RHEL6 sssd-client-1.9.2-82.el6.x86_64 sssd-1.9.2-82.el6.x86_64
Authentication works, the primary group is returned. getent group <GROUPNAME> returns the group and all of the members. Once getent group <GROUPNAME> has been run the queried group will show up on the users list until the cache expires/is deleted.
/etc/sssd/sssd.conf contains
ldap_schema = rfc2307 ldap_search_base = ou=Group,o=<DOMAIN>
With debug enabled the log shows the query for the user's information, then the users primary group. There is no evidence of any query to return the users additional groups.
ldapsearch "(&(memberUid=<USER>)(objectclass=posixGroup)(cn=)(gidNumber=))"
returns the expected list of all groups
Output:# hadoop, group, <DOMAIN> dn: cn=hadoop,ou=group,o=<DOMAIN> objectClass: posixGroup objectClass: top cn: hadoop gidNumber: <GID> memberUid: <USER> memberUid: <USER> memberUid: <USER>
Please close - identified the problem
the SUN LDAP proxy we are using is returning duplicates of all records which - from googling sssd considers this an error (rightly so) and will 'fail', while RH5 would ignore and continue.
Can you give us an example of the wrong duplicate? Does Sun LDAP consider this a bug or a feature?
It gets more complicated the issue crops up on a SUN LDAP proxy server querying a SUN Directory server (that's ~8 years old). I quickly installed an OpenLDAP proxy and configured it to query the same directory server. It does not exhibit the same duplicate record issue. Directly querying the SUN Directory server also does not have duplicates.
But for kicks and giggles here you go
10.50.20.231 == SUN LDAP Proxy
10.50.20.235 == OpenLDAP Proxy
ldapsearch -x -h 10.50.20.231 "uid=kvollmer" ... # numResponses: 3 # numEntries: 2 ldapsearch -x -h 10.50.20.235 "uid=kvollmer" ... # numResponses: 2 # numEntries: 1
Records against the SUN LDAP proxy are perfectly identical. I'm currently in the process of seeing if we have that mis-configured somehow, so at this point I would put all of the blame squarly on our shoulders. Even if it's not our fault we're running something so beyond old, and unsupported that I would hesitate to troubleshoot beyond "please update"
OK, thank you for the explanation. For now, I'm going to close the ticket. Kindly reopen if you find out the problem actually is in SSSD.
resolution: => worksforme status: new => closed
Metadata Update from @vollmeka: - Issue set to the milestone: NEEDS_TRIAGE
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/3219
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Login to comment on this ticket.