4:01 p.m.
Hello,
sssd appears to bind successfully, but when it tries to fetch user information id balks.
Here is a snippit from the log file immediately after the successful bind.
(Tue Feb 19 13:49:14 2013) [sssd[be[SIBYLS]]] [simple_bind_done] (0x0080): Bind result:
Success(0), no errmsg set
(Tue Feb 19 13:49:14 2013) [sssd[be[SIBYLS]]] [fo_set_port_status] (0x0100): Marking port
389 of server 'mymachine' as 'working'
(Tue Feb 19 13:49:14 2013) [sssd[be[SIBYLS]]] [set_server_common_status] (0x0100): Marking
server 'mymachine' as 'working'
(Tue Feb 19 13:49:14 2013) [sssd[be[SIBYLS]]] [sdap_get_generic_ext_done] (0x0040):
Unexpected result from ldap: Protocol error(2), Dereference control: attribute decoding
error
(Tue Feb 19 13:49:14 2013) [sssd[be[SIBYLS]]] [sdap_x_deref_search_done] (0x0100):
sdap_get_generic_ext_recv failed [5]: Input/output error
(Tue Feb 19 13:49:14 2013) [sssd[be[SIBYLS]]] [sdap_deref_search_done] (0x0040):
dereference processing failed [5]: Input/output error
(Tue Feb 19 13:49:14 2013) [sssd[be[SIBYLS]]] [sdap_nested_done] (0x0020): Nested group
processing failed: [5][Input/output error]
(Tue Feb 19 13:49:14 2013) [sssd[be[SIBYLS]]] [acctinfo_callback] (0x0100): Request
processed. Returned 3,5,Group lookup failed
(Tue Feb 19 13:49:14 2013) [sssd[nss]] [nss_cmd_getgrgid_dp_callback] (0x0040): Unable to
get information from Data Provider
Error: 3, 5, Group lookup failed
Will try to return what we have in cache
ldpasearch works fine:
ldapsearch -x -D "uid=nss,dc=mydomain" -b "dc=mydomain" -w secret
"cn=somegroupname" -LL
and produces copious information about all the members of "somegroupname"
this is causing a major headache as a simple ls -l will hang the system.
Thanks,
Scott
7:22 p.m.
On 02/19/2013 05:01 PM, Scott Classen wrote:
Hello,
sssd appears to bind successfully, but when it tries to fetch user information id balks.
Here is a snippit from the log file immediately after the successful bind.
(Tue Feb 19 13:49:14 2013) [sssd[be[SIBYLS]]] [simple_bind_done] (0x0080): Bind result:
Success(0), no errmsg set
(Tue Feb 19 13:49:14 2013) [sssd[be[SIBYLS]]] [fo_set_port_status] (0x0100): Marking port
389 of server 'mymachine' as 'working'
(Tue Feb 19 13:49:14 2013) [sssd[be[SIBYLS]]] [set_server_common_status] (0x0100):
Marking server 'mymachine' as 'working'
(Tue Feb 19 13:49:14 2013) [sssd[be[SIBYLS]]] [sdap_get_generic_ext_done] (0x0040):
Unexpected result from ldap: Protocol error(2), Dereference control: attribute decoding
error
(Tue Feb 19 13:49:14 2013) [sssd[be[SIBYLS]]] [sdap_x_deref_search_done] (0x0100):
sdap_get_generic_ext_recv failed [5]: Input/output error
(Tue Feb 19 13:49:14 2013) [sssd[be[SIBYLS]]] [sdap_deref_search_done] (0x0040):
dereference processing failed [5]: Input/output error
(Tue Feb 19 13:49:14 2013) [sssd[be[SIBYLS]]] [sdap_nested_done] (0x0020): Nested group
processing failed: [5][Input/output error]
(Tue Feb 19 13:49:14 2013) [sssd[be[SIBYLS]]] [acctinfo_callback] (0x0100): Request
processed. Returned 3,5,Group lookup failed
(Tue Feb 19 13:49:14 2013) [sssd[nss]] [nss_cmd_getgrgid_dp_callback] (0x0040): Unable to
get information from Data Provider
Error: 3, 5, Group lookup failed
Will try to return what we have in cache
ldpasearch works fine:
ldapsearch -x -D "uid=nss,dc=mydomain" -b "dc=mydomain" -w secret
"cn=somegroupname" -LL
and produces copious information about all the members of "somegroupname"
this is causing a major headache as a simple ls -l will hang the system.
What is the version of SSSD and what kind of directory it uses?
It seems, based on the error message, that LDAP server supplies a deref
control that SSSD fails to parse. Is there something special in your
LDAP server or something changed recently?
LDAP search might work OK because it does not try to process the control.
Is this an issue that suddenly started to happen or it just does not
work out of box?
In either cases the reason for this is most likely on the server side.
Is there any way to get more info from the server side about what kind
of control was actually sent?
Thanks,
Scott
_______________________________________________
sssd-users mailing list
sssd-users(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users
--
Thank you,
Dmitri Pal
Sr. Engineering Manager for IdM portfolio
Red Hat Inc.
-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
2:24 a.m.
On Tue, Feb 19, 2013 at 08:22:23PM -0500, Dmitri Pal wrote:
On 02/19/2013 05:01 PM, Scott Classen wrote:
> Hello,
>
> sssd appears to bind successfully, but when it tries to fetch user information id
balks. Here is a snippit from the log file immediately after the successful bind.
>
> (Tue Feb 19 13:49:14 2013) [sssd[be[SIBYLS]]] [simple_bind_done] (0x0080): Bind
result: Success(0), no errmsg set
> (Tue Feb 19 13:49:14 2013) [sssd[be[SIBYLS]]] [fo_set_port_status] (0x0100): Marking
port 389 of server 'mymachine' as 'working'
> (Tue Feb 19 13:49:14 2013) [sssd[be[SIBYLS]]] [set_server_common_status] (0x0100):
Marking server 'mymachine' as 'working'
> (Tue Feb 19 13:49:14 2013) [sssd[be[SIBYLS]]] [sdap_get_generic_ext_done] (0x0040):
Unexpected result from ldap: Protocol error(2), Dereference control: attribute decoding
error
> (Tue Feb 19 13:49:14 2013) [sssd[be[SIBYLS]]] [sdap_x_deref_search_done] (0x0100):
sdap_get_generic_ext_recv failed [5]: Input/output error
> (Tue Feb 19 13:49:14 2013) [sssd[be[SIBYLS]]] [sdap_deref_search_done] (0x0040):
dereference processing failed [5]: Input/output error
> (Tue Feb 19 13:49:14 2013) [sssd[be[SIBYLS]]] [sdap_nested_done] (0x0020): Nested
group processing failed: [5][Input/output error]
> (Tue Feb 19 13:49:14 2013) [sssd[be[SIBYLS]]] [acctinfo_callback] (0x0100): Request
processed. Returned 3,5,Group lookup failed
> (Tue Feb 19 13:49:14 2013) [sssd[nss]] [nss_cmd_getgrgid_dp_callback] (0x0040):
Unable to get information from Data Provider
> Error: 3, 5, Group lookup failed
> Will try to return what we have in cache
>
>
> ldpasearch works fine:
>
> ldapsearch -x -D "uid=nss,dc=mydomain" -b "dc=mydomain" -w
secret "cn=somegroupname" -LL
>
> and produces copious information about all the members of "somegroupname"
>
>
> this is causing a major headache as a simple ls -l will hang the system.
What is the version of SSSD and what kind of directory it uses?
It seems, based on the error message, that LDAP server supplies a deref
control that SSSD fails to parse. Is there something special in your
LDAP server or something changed recently?
yes, it would be good to know type and version of your LDAP server. In
the meantime you can try to switch of dereference by setting
'ldap_deref_threshold = 0' in you sssd.conf.
bye,
Sumit
LDAP search might work OK because it does not try to process the
control.
Is this an issue that suddenly started to happen or it just does not
work out of box?
In either cases the reason for this is most likely on the server side.
Is there any way to get more info from the server side about what kind
of control was actually sent?
> Thanks,
> Scott
>
>
>
>
> _______________________________________________
> sssd-users mailing list
> sssd-users(a)lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/sssd-users
--
Thank you,
Dmitri Pal
Sr. Engineering Manager for IdM portfolio
Red Hat Inc.
-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
_______________________________________________
sssd-users mailing list
sssd-users(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users
10:56 a.m.
Well I got SSSD and LDAP working so I thought I'd post something here for
posterity's sake.
On Feb 19, 2013, at 5:22 PM, Dmitri Pal wrote:
On 02/19/2013 05:01 PM, Scott Classen wrote:
> Hello,
>
> sssd appears to bind successfully, but when it tries to fetch user information id
balks. Here is a snippit from the log file immediately after the successful bind.
>
> (Tue Feb 19 13:49:14 2013) [sssd[be[SIBYLS]]] [simple_bind_done] (0x0080): Bind
result: Success(0), no errmsg set
> (Tue Feb 19 13:49:14 2013) [sssd[be[SIBYLS]]] [fo_set_port_status] (0x0100): Marking
port 389 of server 'mymachine' as 'working'
> (Tue Feb 19 13:49:14 2013) [sssd[be[SIBYLS]]] [set_server_common_status] (0x0100):
Marking server 'mymachine' as 'working'
> (Tue Feb 19 13:49:14 2013) [sssd[be[SIBYLS]]] [sdap_get_generic_ext_done] (0x0040):
Unexpected result from ldap: Protocol error(2), Dereference control: attribute decoding
error
> (Tue Feb 19 13:49:14 2013) [sssd[be[SIBYLS]]] [sdap_x_deref_search_done] (0x0100):
sdap_get_generic_ext_recv failed [5]: Input/output error
> (Tue Feb 19 13:49:14 2013) [sssd[be[SIBYLS]]] [sdap_deref_search_done] (0x0040):
dereference processing failed [5]: Input/output error
> (Tue Feb 19 13:49:14 2013) [sssd[be[SIBYLS]]] [sdap_nested_done] (0x0020): Nested
group processing failed: [5][Input/output error]
> (Tue Feb 19 13:49:14 2013) [sssd[be[SIBYLS]]] [acctinfo_callback] (0x0100): Request
processed. Returned 3,5,Group lookup failed
> (Tue Feb 19 13:49:14 2013) [sssd[nss]] [nss_cmd_getgrgid_dp_callback] (0x0040):
Unable to get information from Data Provider
> Error: 3, 5, Group lookup failed
> Will try to return what we have in cache
>
>
> ldpasearch works fine:
>
> ldapsearch -x -D "uid=nss,dc=mydomain" -b "dc=mydomain" -w secret
"cn=somegroupname" -LL
>
> and produces copious information about all the members of "somegroupname"
>
>
> this is causing a major headache as a simple ls -l will hang the system.
>
What is the version of SSSD and what kind of directory it uses?
SSSD version 1.8.0 as distributed through CentOS 6.
OpenLDAP version 2.4.32 built from source
It seems, based on the error message, that LDAP server supplies a
deref control that SSSD fails to parse. Is there something special in your LDAP server or
something changed recently?
Nothing has changed with the OpenLDAP server. We do have some special schemas, but I
don't think that is the problem
LDAP search might work OK because it does not try to process the
control.
Is this an issue that suddenly started to happen or it just does not work out of box?
In either cases the reason for this is most likely on the server side.
Is there any way to get more info from the server side about what kind of control was
actually sent?
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
2:41 p.m.
On Wed, Feb 20, 2013 at 08:56:10AM -0800, Scott Classen wrote:
Well I got SSSD and LDAP working so I thought I'd post something here for
posterity's sake.
On Feb 19, 2013, at 5:22 PM, Dmitri Pal wrote:
> On 02/19/2013 05:01 PM, Scott Classen wrote:
>> Hello,
>>
>> sssd appears to bind successfully, but when it tries to fetch user information
id balks. Here is a snippit from the log file immediately after the successful bind.
>>
>> (Tue Feb 19 13:49:14 2013) [sssd[be[SIBYLS]]] [simple_bind_done] (0x0080): Bind
result: Success(0), no errmsg set
>> (Tue Feb 19 13:49:14 2013) [sssd[be[SIBYLS]]] [fo_set_port_status] (0x0100):
Marking port 389 of server 'mymachine' as 'working'
>> (Tue Feb 19 13:49:14 2013) [sssd[be[SIBYLS]]] [set_server_common_status]
(0x0100): Marking server 'mymachine' as 'working'
>> (Tue Feb 19 13:49:14 2013) [sssd[be[SIBYLS]]] [sdap_get_generic_ext_done]
(0x0040): Unexpected result from ldap: Protocol error(2), Dereference control: attribute
decoding error
>> (Tue Feb 19 13:49:14 2013) [sssd[be[SIBYLS]]] [sdap_x_deref_search_done]
(0x0100): sdap_get_generic_ext_recv failed [5]: Input/output error
>> (Tue Feb 19 13:49:14 2013) [sssd[be[SIBYLS]]] [sdap_deref_search_done] (0x0040):
dereference processing failed [5]: Input/output error
>> (Tue Feb 19 13:49:14 2013) [sssd[be[SIBYLS]]] [sdap_nested_done] (0x0020):
Nested group processing failed: [5][Input/output error]
>> (Tue Feb 19 13:49:14 2013) [sssd[be[SIBYLS]]] [acctinfo_callback] (0x0100):
Request processed. Returned 3,5,Group lookup failed
>> (Tue Feb 19 13:49:14 2013) [sssd[nss]] [nss_cmd_getgrgid_dp_callback] (0x0040):
Unable to get information from Data Provider
>> Error: 3, 5, Group lookup failed
>> Will try to return what we have in cache
>>
>>
>> ldpasearch works fine:
>>
>> ldapsearch -x -D "uid=nss,dc=mydomain" -b "dc=mydomain" -w
secret "cn=somegroupname" -LL
>>
>> and produces copious information about all the members of
"somegroupname"
>>
>>
>> this is causing a major headache as a simple ls -l will hang the system.
>>
>
> What is the version of SSSD and what kind of directory it uses?
SSSD version 1.8.0 as distributed through CentOS 6.
OpenLDAP version 2.4.32 built from source
> It seems, based on the error message, that LDAP server supplies a deref control that
SSSD fails to parse. Is there something special in your LDAP server or something changed
recently?
Nothing has changed with the OpenLDAP server. We do have some special schemas, but I
don't think that is the problem
> LDAP search might work OK because it does not try to process the control.
>
> Is this an issue that suddenly started to happen or it just does not work out of
box?
> In either cases the reason for this is most likely on the server side.
> Is there any way to get more info from the server side about what kind of control
was actually sent?
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.
3:20 p.m.
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
1:59 a.m.
On 02/20/2013 04:20 PM, 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
Can it be something in root DN?
I agree that enumerate = true is just hiding the problem.
We generally do not recommend turning on enumeration. It might work for
you if your user base is small but it does not scale well for the cases
when there is a lot of data to download.
_______________________________________________
sssd-users mailing list
sssd-users(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users
--
Thank you,
Dmitri Pal
Sr. Engineering Manager for IdM portfolio
Red Hat Inc.
-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
5:44 a.m.
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.
4:52 p.m.
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?
2808
days inactive
2810
days old
sssd-users@lists.fedorahosted.org
8 comments
4 participants
participants (4)
-
Dmitri Pal -
Jakub Hrozek -
Scott Classen -
Sumit Bose