Bug 627021 - nss group not working properly
nss group not working properly
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: sssd (Show other bugs)
13
All Linux
low Severity medium
: ---
: ---
Assigned To: Stephen Gallagher
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-08-24 17:24 EDT by Brian LaMere
Modified: 2010-08-24 19:51 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-08-24 18:52:54 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
sssd.conf file (sanitized) (3.92 KB, application/octet-stream)
2010-08-24 17:24 EDT, Brian LaMere
no flags Details
sssd_LDAP.log (sanitized) (49.62 KB, text/x-log)
2010-08-24 17:25 EDT, Brian LaMere
no flags Details
sssd_nss.log (sanitized) (8.46 KB, text/x-log)
2010-08-24 17:25 EDT, Brian LaMere
no flags Details

  None (edit)
Description Brian LaMere 2010-08-24 17:24:14 EDT
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.
Comment 1 Brian LaMere 2010-08-24 17:25:33 EDT
Created attachment 440777 [details]
sssd_LDAP.log (sanitized)
Comment 2 Brian LaMere 2010-08-24 17:25:59 EDT
Created attachment 440778 [details]
sssd_nss.log (sanitized)
Comment 3 Brian LaMere 2010-08-24 17:29:42 EDT
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 ;)
Comment 4 Brian LaMere 2010-08-24 17:46:42 EDT
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.
Comment 5 Simo Sorce 2010-08-24 18:52:54 EDT
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
Comment 6 Brian LaMere 2010-08-24 19:51:06 EDT
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 :)

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