You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've got a setup that for some reason is failing to provide expected responses via the dereference control (the server is IPA master with 389ds 1.3.3.a2 built from git in Februari).
While trying to login with admin the HBAC code (I think) tried to find the Hosts and a dereference control returned unexpected results, the user login then failed with a System error:
This is the log I could get before fixing the problem (by removing the test group which was not part of any HBAC rule).
(Tue Jun 17 22:32:29 2014) [sssd[be[ipa.dev.lan]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(objectClass=ipaHost)(fqdn=idp.ipa.dev.lan))][cn=accounts,dc=ipa,dc=dev,dc=lan].
(Tue Jun 17 22:32:29 2014) [sssd[be[ipa.dev.lan]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectClass]
(Tue Jun 17 22:32:29 2014) [sssd[be[ipa.dev.lan]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [cn]
(Tue Jun 17 22:32:29 2014) [sssd[be[ipa.dev.lan]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [fqdn]
(Tue Jun 17 22:32:29 2014) [sssd[be[ipa.dev.lan]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [serverHostname]
(Tue Jun 17 22:32:29 2014) [sssd[be[ipa.dev.lan]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [memberOf]
(Tue Jun 17 22:32:29 2014) [sssd[be[ipa.dev.lan]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaSshPubKey]
(Tue Jun 17 22:32:29 2014) [sssd[be[ipa.dev.lan]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaUniqueID]
(Tue Jun 17 22:32:29 2014) [sssd[be[ipa.dev.lan]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 21
(Tue Jun 17 22:32:30 2014) [sssd[be[ipa.dev.lan]]] [sdap_process_result] (0x2000): Trace: sh[0x7f0991ad2240], connected[1], ops[0x7f0991a99e00], ldap[0x7f0991ad2570]
(Tue Jun 17 22:32:30 2014) [sssd[be[ipa.dev.lan]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY]
(Tue Jun 17 22:32:30 2014) [sssd[be[ipa.dev.lan]]] [sdap_parse_entry] (0x4000): OriginalDN: [fqdn=idp.ipa.dev.lan,cn=computers,cn=accounts,dc=ipa,dc=dev,dc=lan].
(Tue Jun 17 22:32:30 2014) [sssd[be[ipa.dev.lan]]] [sdap_parse_range] (0x2000): No sub-attributes for [objectClass]
(Tue Jun 17 22:32:30 2014) [sssd[be[ipa.dev.lan]]] [sdap_parse_range] (0x2000): No sub-attributes for [cn]
(Tue Jun 17 22:32:30 2014) [sssd[be[ipa.dev.lan]]] [sdap_parse_range] (0x2000): No sub-attributes for [fqdn]
(Tue Jun 17 22:32:30 2014) [sssd[be[ipa.dev.lan]]] [sdap_parse_range] (0x2000): No sub-attributes for [serverHostname]
(Tue Jun 17 22:32:30 2014) [sssd[be[ipa.dev.lan]]] [sdap_parse_range] (0x2000): No sub-attributes for [memberOf]
(Tue Jun 17 22:32:30 2014) [sssd[be[ipa.dev.lan]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipaSshPubKey]
(Tue Jun 17 22:32:30 2014) [sssd[be[ipa.dev.lan]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipaUniqueID]
(Tue Jun 17 22:32:30 2014) [sssd[be[ipa.dev.lan]]] [sdap_process_result] (0x2000): Trace: sh[0x7f0991ad2240], connected[1], ops[0x7f0991a99e00], ldap[0x7f0991ad2570]
(Tue Jun 17 22:32:30 2014) [sssd[be[ipa.dev.lan]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT]
(Tue Jun 17 22:32:30 2014) [sssd[be[ipa.dev.lan]]] [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg set
(Tue Jun 17 22:32:30 2014) [sssd[be[ipa.dev.lan]]] [sdap_get_generic_ext_done] (0x2000): Total count [0]
(Tue Jun 17 22:32:30 2014) [sssd[be[ipa.dev.lan]]] [sdap_has_deref_support] (0x0400): The server supports deref method OpenLDAP
(Tue Jun 17 22:32:30 2014) [sssd[be[ipa.dev.lan]]] [sdap_deref_search_send] (0x2000): Server supports OpenLDAP deref
(Tue Jun 17 22:32:30 2014) [sssd[be[ipa.dev.lan]]] [sdap_x_deref_search_send] (0x0400): Dereferencing entry [fqdn=idp.ipa.dev.lan,cn=computers,cn=accounts,dc=ipa,dc=dev,dc=lan] using OpenLDAP deref
(Tue Jun 17 22:32:30 2014) [sssd[be[ipa.dev.lan]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [no filter][fqdn=idp.ipa.dev.lan,cn=computers,cn=accounts,dc=ipa,dc=dev,dc=lan].
(Tue Jun 17 22:32:30 2014) [sssd[be[ipa.dev.lan]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectClass]
(Tue Jun 17 22:32:30 2014) [sssd[be[ipa.dev.lan]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [cn]
(Tue Jun 17 22:32:30 2014) [sssd[be[ipa.dev.lan]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [memberOf]
(Tue Jun 17 22:32:30 2014) [sssd[be[ipa.dev.lan]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaUniqueID]
(Tue Jun 17 22:32:30 2014) [sssd[be[ipa.dev.lan]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 22
(Tue Jun 17 22:32:30 2014) [sssd[be[ipa.dev.lan]]] [sdap_process_result] (0x2000): Trace: sh[0x7f0991ad2240], connected[1], ops[0x7f0991a99e00], ldap[0x7f0991ad2570]
(Tue Jun 17 22:32:30 2014) [sssd[be[ipa.dev.lan]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing!
(Tue Jun 17 22:32:30 2014) [sssd[be[ipa.dev.lan]]] [sdap_process_result] (0x2000): Trace: sh[0x7f0991ad2240], connected[1], ops[0x7f0991a99e00], ldap[0x7f0991ad2570]
(Tue Jun 17 22:32:30 2014) [sssd[be[ipa.dev.lan]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY]
(Tue Jun 17 22:32:30 2014) [sssd[be[ipa.dev.lan]]] [sdap_x_deref_parse_entry] (0x0400): Got deref control
(Tue Jun 17 22:32:30 2014) [sssd[be[ipa.dev.lan]]] [sdap_parse_deref] (0x1000): Dereferenced DN: cn=test,cn=hostgroups,cn=accounts,dc=ipa,dc=dev,dc=lan
(Tue Jun 17 22:32:30 2014) [sssd[be[ipa.dev.lan]]] [sdap_parse_deref] (0x0080): Dereferenced entry [cn=test,cn=hostgroups,cn=accounts,dc=ipa,dc=dev,dc=lan] has no attributes
(Tue Jun 17 22:32:30 2014) [sssd[be[ipa.dev.lan]]] [sdap_x_deref_parse_entry] (0x0040): sdap_parse_deref failed [22]: Invalid argument
(Tue Jun 17 22:32:30 2014) [sssd[be[ipa.dev.lan]]] [sdap_get_generic_ext_done] (0x0020): reply parsing callback failed.
(Tue Jun 17 22:32:30 2014) [sssd[be[ipa.dev.lan]]] [sdap_x_deref_search_done] (0x0100): sdap_get_generic_ext_recv failed [22]: Invalid argument
(Tue Jun 17 22:32:30 2014) [sssd[be[ipa.dev.lan]]] [sdap_deref_search_done] (0x0040): dereference processing failed [22]: Invalid argument
(Tue Jun 17 22:32:30 2014) [sssd[be[ipa.dev.lan]]] [ipa_hostgroup_info_done] (0x0040): Error [22][Invalid argument]
(Tue Jun 17 22:32:30 2014) [sssd[be[ipa.dev.lan]]] [sdap_id_op_done] (0x4000): releasing operation connection
(Tue Jun 17 22:32:30 2014) [sssd[be[ipa.dev.lan]]] [be_pam_handler_callback] (0x0100): Backend returned: (3, 4, <NULL>) [Internal Error (System error)]
(Tue Jun 17 22:32:30 2014) [sssd[be[ipa.dev.lan]]] [be_pam_handler_callback] (0x0100): Sending result [4][ipa.dev.lan]
(Tue Jun 17 22:32:30 2014) [sssd[be[ipa.dev.lan]]] [be_pam_handler_callback] (0x0100): Sent result [4][ipa.dev.lan]
It is interesting to note that the admins group later also shows the same behaviour during an initgroups but this didn't trigger a login failure.
I agree this failure should not be fatal. I thought we made dereference failures non-fatal already but maybe I'm confusing that with the identity lookup code.
We should also inspect other parts of sssd where dereference is used to make sure we can fall back to individual lookups.
I think we should lower the priority of this bug. Given that this happens in IPA code only where we know 389DS is on the server side and the failure Simo was seeing was caused by https://fedorahosted.org/freeipa/ticket/4389 I don't think we need to rush with the fix.
Given that the error was on the server side, moving to 1.14. We should be more defensive and retry no-dereference lookups, but in the normal case where the DS is not broken, the dereference should be available.
Cloned from Pagure issue: https://pagure.io/SSSD/sssd/issue/2363
I've got a setup that for some reason is failing to provide expected responses via the dereference control (the server is IPA master with 389ds 1.3.3.a2 built from git in Februari).
While trying to login with admin the HBAC code (I think) tried to find the Hosts and a dereference control returned unexpected results, the user login then failed with a System error:
This is the log I could get before fixing the problem (by removing the test group which was not part of any HBAC rule).
It is interesting to note that the admins group later also shows the same behaviour during an initgroups but this didn't trigger a login failure.
Comments
Comment from jhrozek at 2014-06-18 11:22:33
I agree this failure should not be fatal. I thought we made dereference failures non-fatal already but maybe I'm confusing that with the identity lookup code.
We should also inspect other parts of sssd where dereference is used to make sure we can fall back to individual lookups.
Comment from jhrozek at 2014-06-25 15:23:29
I think we should lower the priority of this bug. Given that this happens in IPA code only where we know 389DS is on the server side and the failure Simo was seeing was caused by https://fedorahosted.org/freeipa/ticket/4389 I don't think we need to rush with the fix.
Comment from jhrozek at 2014-06-25 15:23:50
Fields changed
priority: major => minor
Comment from jhrozek at 2014-06-26 17:06:58
Given that the error was on the server side, moving to 1.14. We should be more defensive and retry no-dereference lookups, but in the normal case where the DS is not broken, the dereference should be available.
milestone: NEEDS_TRIAGE => SSSD 1.14 beta
Comment from dpal at 2014-07-03 15:17:40
Fields changed
rhbz: => todo
Comment from jhrozek at 2016-02-16 14:25:09
This is a duplicate of #2605 (which has much nicer description, so I'm closing this one..)
mark: => 0
resolution: => duplicate
sensitive: => 0
status: new => closed
Comment from jhrozek at 2016-09-11 22:10:51
Fields changed
rhbz: todo => 0
Comment from simo at 2017-02-24 14:58:13
Metadata Update from @Simo:
The text was updated successfully, but these errors were encountered: