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?