On Fri, Apr 19, 2013 at 07:09:09PM +0200, steve wrote:
On 04/19/2013 06:53 PM, Jakub Hrozek wrote:
>On Fri, Apr 19, 2013 at 06:33:41PM +0200, steve wrote:
>>On 04/19/2013 05:51 PM, Jakub Hrozek wrote:
>>>On Fri, Apr 19, 2013 at 04:48:15PM +0200, steve wrote:
>>>>Hi
>>>>The LDAP_PROTOCOL_ERROR occurs once during user authentication and
>>>>again upon logging out. It does not occur with getent or at ny other
>>>>time during the session. I'm almost certain that this has something
>>>>to do with sssd; users authenticating against nslcd or winbind do
>>>>not produce this response from the Samba4 ldap. I'll post over on
>>>>samba-technical to see if they can help.
>>>>Cheers,
>>>>Steve
>>>Yes, but can you post the relevent snippet from the logs? They should
>>>include the query that is failing.
>>Hi
>>I put the level 9 logs here:
>>https://dl.dropboxusercontent.com/u/45150875/sssd.client.log.tar
>>
>>I'm not a dev but I'll try: Here is where it fails getting the
>>groups for the user (from sssd_default.log) I think that this is
>>what produces the LDAP_PROTOCOL_ERROR.
>Yes, but that's the same error as before. Let me explain the log
>snippet in a more detail.
>
>>[sssd[be[default]]] [sdap_ldap_connect_callback_add] (0x1000): New LDAP
connection to [ldap://dolores.site/CN=Configuration,DC=dolores,DC=site] with fd [22].
>>[sssd[be[default]]] [sdap_rebind_proc] (0x1000): Successfully bind to
[ldap://dolores.site/CN=Configuration,DC=dolores,DC=site].
> ^^^^^^^^
>An LDAP referral was followed here.
>
>>[sssd[be[default]]] [sdap_process_message] (0x4000): Message type:
[LDAP_RES_SEARCH_REFERENCE]
>>[sssd[be[default]]] [sdap_process_result] (0x2000): Trace: sh[0x893d088],
connected[1], ops[0x895ef58], ldap[0x8933328]
>>[sssd[be[default]]] [sdap_process_message] (0x4000): Message type:
[LDAP_RES_SEARCH_REFERENCE]
>>[sssd[be[default]]] [sdap_process_result] (0x2000): Trace: sh[0x893d088],
connected[1], ops[0x895ef58], ldap[0x8933328]
>>[sssd[be[default]]] [sdap_process_message] (0x4000): Message type:
[LDAP_RES_SEARCH_REFERENCE]
>>[sssd[be[default]]] [sdap_process_result] (0x2000): Trace: sh[0x893d088],
connected[1], ops[0x895ef58], ldap[0x8933328]
>>[sssd[be[default]]] [sdap_process_result] (0x0040): ldap_result error: [Can't
contact LDAP server]
>>[sssd[be[default]]] [sdap_handle_release] (0x2000): Trace: sh[0x893d088],
connected[1], ops[0x895ef58], ldap[0x8933328], destructor_lock[0], release_memory[0]
>>[sssd[be[default]]] [remove_connection_callback] (0x4000): Successfully removed
connection callback.
>>[sssd[be[default]]] [server_setup] (0x0400): CONFDB: /var/lib/sss/db/config.ldb
> ^^^^^
>server_setup is the first function that a new sssd_be instance runs
>after it crashed and was respawned.
>
>>[sssd[be[default]]] [recreate_ares_channel] (0x0100): Initializing new c-ares
channel
>>[sssd[be[default]]] [resolv_get_family_order] (0x1000): Lookup order: ipv4_first
>So I'd like to ask you to try two things:
>1) run the same case with ldap_referrals=False in the sssd.conf config
>file to stop SSSD from following referrals
>2) if possible, gather the backtrace or the core file
>
>Thank you!
Hi. Brilliant. With ldap_referrals=False it works instantaneously. I
can remove steve3 from staff and it is reflected immediately after
logging in by id and getent group staff. Similarly for re-adding him
to the group. Upon logging in, he appears immediately. Do we lose
anything by using ldap_referrals=False?
Cheers,
Steve
I'm glad it finally works for you!
About needing the referrals - I'm not entirely sure about S4, but if it
behaves just like AD, then you don't lose any data unless you use
partial replication.
I'm still quite concerned about the crash you saw. Any chance you could
get us the backtrace? Even if sssd was not configured optimally, it
should never ever crash. (Then again, the problem might have been in
openldap as we use libldap's referral chasing). The backtrace would tell
us for sure.