Created attachment 440776 [details] sssd.conf file (sanitized) Description of problem: secondary groups not working properly Version-Release number of selected component (if applicable): Fedora 13 client, 389 (Fedora) Directory Server running on Fedora 13. latest versions (sssd-1.2.2-19.fc13.i686, 389-ds-base-1.2.6-0.1.a1.fc13.x86_64) How reproducible: 100% Steps to Reproduce: 1. install sssd with basic LDAP section as in example 2. "getent group" shows ldap groups, with no members 3. "id (someuser)" shows ldap user, with no secondary groups Actual results: Expected results: Additional info: This isn't bug 580402, since rfc2307 is what 389 DS uses. Wasn't sure if this is the same as bug 626775, but I followed the steps you requested at the end there and am attaching what you requested there. I don't have precisely the same problem as him though - the system knows what the groups are, it just isn't putting people into the groups. Also note that the directory is currently *very* small, with only a couple dozen users currently. So lookups should be very fast. Also, looking at the logs I decided to do the following: ================================ [root@c03c01 ~]# ldapsearch -x -L "(&(member=testuser)(objectclass=posixGroup))" version: 1 # # LDAPv3 # base <dc=cukerinteractive,dc=com> (default) with scope subtree # filter: (&(memberUid=testuser)(objectclass=posixGroup)) # requesting: ALL # # search result # numResponses: 1 =================================== That should have results (presumably). All other services are working well, nss_ldap works great when I use it instead. Note that this means I can't restrict logon based on group membership, naturally.
Created attachment 440777 [details] sssd_LDAP.log (sanitized)
Created attachment 440778 [details] sssd_nss.log (sanitized)
note that I don't see memberUid as defined for the groups within 389 Directory Server; but as mentioned, this doesn't keep other services (nslcd, nscd, etc) from working properly. I can change how users are created if necessary, I'm just wanting to verify that sssd needs something different than what nslcd requires. Also note that if I weren't trying to move to sssd, then it wouldn't be an issue; I never know if I come off as harsh in a bug report ;)
one last comment - In my initial comment I said I tested an ldapsearch against member; that was a second test, I also tested using memberuid. Secondly, while I don't see memberUid defined for groups, it is listed as an allowed attribute, and I can set it. When I do set it, sssd works (for that one group). neither nslcd nor nscd required I set this, however; for those, I'm guessing they used the uniqueMember attribute, which has member dn's instead? ============================== [root@c03c01 sssd]# ldapsearch -x -LLL "cn=testgroup" dn: cn=testgroup,ou=Groups,dc=EXAMPLE,dc=com memberUid: brian cn: testgroup uniqueMember: uid=testuser,ou=People,dc=EXAMPLE,dc=com objectClass: top objectClass: groupofuniquenames objectClass: posixgroup gidNumber: xxxx [root@c03c01 sssd]# ======================= Final note: Putting members in to groups using the 389 console (the GUI for Fedora Directory Server) does not assign the memberUid attribute. Again, just verifying that this attribute is intended to be required by sssd when it doesn't seem to be by what it replaces; I can change the ldif changetype:modify and changetype:add templates I use (since in production, the users will be created via batch processes, not a GUI) to assign the memberUid if so.
Your server is using the rfc2307bis schema with the uniqueMember attribute for group members. You want to change ldap_schema to: ldap_schema = rfc2307bis and add: ldap_group_member = uniqueMember
According to http://fedoraproject.org/wiki/Talk:Design/SSSD#24_Feb_2010 - 389 uses rfc2307 (user "Duffy" made that comment), not rfc2307bis. The difference between rfc2307 and rfc2307bis is that the former uses "memberUid," and the later "member," I thought? That's what the example in sssd.conf says, at least. No mention of "uniqueMember" that I see. At the very least, if FreeIPA and 389 Directory Server both do rfc2307bis, shouldn't sssd default to the same thing the Fedora products sssd would most likely be connecting to, use? And Duffy's suggestion of having 389 use rfc2307 would apparently be incorrect. But yes, making those changes does make it work. Thanks :)