On Feb 21, 2013, at 3:44 AM, Jakub Hrozek wrote: > On Wed, Feb 20, 2013 at 01:20:23PM -0800, Scott Classen wrote: >> On Feb 20, 2013, at 12:41 PM, Jakub Hrozek wrote: >> >>>> So the solution was to add the following line to my sssd.conf file >>>> >>>> enumerate = true >>>> >>>> That's it. >>>> >>>> Everything works now. >>>> >>>> id username returns useful information. >>>> getent works. >>>> ls -l works. >>>> >>>> Not exactly sure why enumerate = true would fix my problem? I would expect >>>> that the underlying mechanism used to gather user/group information from >>>> OpenLDAP would be the same regardless of whether enumeration is turned on >>>> or off. My understanding from reading the sssd documentation is that >>>> enumeration merely caches the user/group information locally. There must >>>> be something else going on that is causes the system to hang when >>>> enumeration is set to false/ >>>> >>>> Anyways that's as far as I got. I'm happy that things are working now. >>>> >>>> Scott >>>> >>> >>> Hi, >>> >>> The dereference processing can only work if the attributes >>> being dereferenced (usually member:) are DNs (DN_SYNTAX_OID). Does your >>> schema maybe touch the member attributes in any way? Do all your groups >>> really use the member attribute and not for instance uniqueMember? >>> >>> Turning the enumeration on merely works around the problem by following >>> a different code path. >> >> Jakub, >> >> my custom schema only extends the posixAccount to add some extra attributes. >> I make no changes to posixGroup. >> >> ldapsearch -ZZ -x -D "uid=nss,dc=mydomain" -b "dc=mydomain" -w secret >> "uniqueMember=*" >> >> returns nothing. >> >> ldapsearch -ZZ -x -D "uid=nss,dc=mydomain" -b "dc=mydomain" -w secret >> "member=*" >> >> returns the 175 groups in my ldap directory. >> >> An example for a specific group (e.g. dvd) would be: >> >> ldapsearch -ZZ -x -D "uid=nss,dc=mydomain" -b "dc=mydomain" -w secret >> "cn=dvd" >> >> # extended LDIF >> # >> # LDAPv3 >> # base <dc=mydomain> with scope subtree >> # filter: cn=dvd >> # requesting: ALL >> # >> >> # dvd, Group, mydomain >> dn: cn=dvd,ou=Group,dc=mydomain >> objectClass: posixGroup >> objectClass: groupOfNames >> objectClass: top >> objectClass: apple-group >> objectClass: extensibleObject >> cn: dvd >> gidNumber: 9075 >> description: dvd burner admin group >> member: uid=user1,ou=People,dc=mydomain >> member: uid=user2,ou=People,dc=mydomain >> >> # search result >> search: 3 >> result: 0 Success >> >> # numResponses: 2 >> # numEntries: 1 >> >> >> I hope this helps. >> >> Scott > > Does the following: > > ldapsearch -x -H ldap://ldap.example.com -E 'deref=member:cn,objectclass' -b > cn=ou=Group,dc=mydomain 'cn=dvd' > > Work for you? The command should yield user1 and user2's cn and > objectclass.
I get the same response regardless of whether the -E "deref=member:cn,objectClass" option is present or not: # ldapsearch -ZZ -x -D "uid=nss,dc=mydomain" -w secret -E "deref=member:cn,objectClass" -b "ou=Group,dc=mydomain" "cn=dvd" -LLL dn: cn=dvd,ou=Group,dc=mydomain objectClass: posixGroup objectClass: groupOfNames objectClass: top objectClass: apple-group objectClass: extensibleObject cn: dvd gidNumber: 9075 description: dvd burner admin group member: uid=user1,ou=People,dc=mydomain member: uid=user2,ou=People,dc=mydomain # ldapsearch -ZZ -x -D "uid=nss,dc=mydomain" -w secret -b "ou=Group,dc=mydomain" "cn=dvd" -LLL dn: cn=dvd,ou=Group,dc=mydomain objectClass: posixGroup objectClass: groupOfNames objectClass: top objectClass: apple-group objectClass: extensibleObject cn: dvd gidNumber: 9075 description: dvd burner admin group member: uid=user1,ou=People,dc=mydomain member: uid=user2,ou=People,dc=mydomain Does this mean deref is broken on my openldap server?
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
