log of group g1 request
sssd.log

sssd configuration
sssd.conf

Actually, this log says exactly the opposite. It shows that we set up an LDAP request, but when we sent it across the wire, we received "[sdap_get_generic_send] (3): ldap_search_ext failed: Can't contact LDAP server"

I'd check the timestamps on things, but I'd hazard a guess that what we're seeing is the kerberos ticket for the LDAP communication expiring.

Rob, can you check to see if it's always a consistent amount of time?

description: I set up an HBAC rule that allows admin to log in from lion to tiger. The rule works if I restart sssd but after a period of time the LDAP connection is lost and causes sssd to fail logins.

A snippet of the log is:

(Fri Apr 30 17:45:16 2010) [sssd[be[greyoak.com]]] [ipa_access_handler] (9): Connection status is [online].
(Fri Apr 30 17:45:16 2010) [sssd[be[greyoak.com]]] [sdap_get_generic_send] (6): calling ldap_search_ext with [(|(&(objectclass=ipaHost)(|(fqdn=tiger.greyoak.com)(serverhostname=tiger.greyoak.com)))(&(objectclass=ipaHost)(|(fqdn=lion.greyoak.com)(serverhostname=lion.greyoak.com))))][cn=computers,cn=accounts,dc=GREYOAK,dc=COM].
(Fri Apr 30 17:45:16 2010) [sssd[be[greyoak.com]]] [sdap_get_generic_send] (7): Requesting attrs: [memberOf]
(Fri Apr 30 17:45:16 2010) [sssd[be[greyoak.com]]] [sdap_get_generic_send] (7): Requesting attrs: [serverHostName]
(Fri Apr 30 17:45:16 2010) [sssd[be[greyoak.com]]] [sdap_get_generic_send] (7): Requesting attrs: [fqdn]
(Fri Apr 30 17:45:16 2010) [sssd[be[greyoak.com]]] [sdap_get_generic_send] (7): Requesting attrs: [objectClass]
(Fri Apr 30 17:45:16 2010) [sssd[be[greyoak.com]]] [sdap_get_generic_send] (7): Requesting attrs: [originalDN]
(Fri Apr 30 17:45:16 2010) [sssd[be[greyoak.com]]] [sdap_get_generic_send] (7): Requesting attrs: [originalMemberOf]
(Fri Apr 30 17:45:16 2010) [sssd[be[greyoak.com]]] [sdap_get_generic_send] (3): ldap_search_ext failed: Can't contact LDAP server
(Fri Apr 30 17:45:16 2010) [sssd[be[greyoak.com]]] [be_pam_handler_callback] (4): Backend returned: (3, 4, ) [Internal Error (Success)]

This affects all communication with the IPA backend. While in this state I added a group in IPA and am unable to fetch it from my client (getent group g1 returns nothing).

I've attached the log for the group request because it seems to isolate the problem better. You can see it trying to connect to LDAP, apparently succeeding, then failing the request.

sssd-1.1.1-3.fc12.x86_64 => I set up an HBAC rule that allows admin to log in from lion to tiger. The rule works if I restart sssd but after a period of time the LDAP connection is lost and causes sssd to fail logins.

A snippet of the log is:
{{{
(Fri Apr 30 17:45:16 2010) [sssd[be[greyoak.com]]] [ipa_access_handler] (9): Connection status is [online].
(Fri Apr 30 17:45:16 2010) [sssd[be[greyoak.com]]] [sdap_get_generic_send] (6): calling ldap_search_ext with [(|(&(objectclass=ipaHost)(|(fqdn=tiger.greyoak.com)(serverhostname=tiger.greyoak.com)))(&(objectclass=ipaHost)(|(fqdn=lion.greyoak.com)(serverhostname=lion.greyoak.com))))][cn=computers,cn=accounts,dc=GREYOAK,dc=COM].
(Fri Apr 30 17:45:16 2010) [sssd[be[greyoak.com]]] [sdap_get_generic_send] (7): Requesting attrs: [memberOf]
(Fri Apr 30 17:45:16 2010) [sssd[be[greyoak.com]]] [sdap_get_generic_send] (7): Requesting attrs: [serverHostName]
(Fri Apr 30 17:45:16 2010) [sssd[be[greyoak.com]]] [sdap_get_generic_send] (7): Requesting attrs: [fqdn]
(Fri Apr 30 17:45:16 2010) [sssd[be[greyoak.com]]] [sdap_get_generic_send] (7): Requesting attrs: [objectClass]
(Fri Apr 30 17:45:16 2010) [sssd[be[greyoak.com]]] [sdap_get_generic_send] (7): Requesting attrs: [originalDN]
(Fri Apr 30 17:45:16 2010) [sssd[be[greyoak.com]]] [sdap_get_generic_send] (7): Requesting attrs: [originalMemberOf]
(Fri Apr 30 17:45:16 2010) [sssd[be[greyoak.com]]] [sdap_get_generic_send] (3): ldap_search_ext failed: Can't contact LDAP server
(Fri Apr 30 17:45:16 2010) [sssd[be[greyoak.com]]] [be_pam_handler_callback] (4): Backend returned: (3, 4, ) [Internal Error (Success)]
}}}
This affects all communication with the IPA backend. While in this state I added a group in IPA and am unable to fetch it from my client (getent group g1 returns nothing).

I've attached the log for the group request because it seems to isolate the problem better. You can see it trying to connect to LDAP, apparently succeeding, then failing the request.

sssd-1.1.1-3.fc12.x86_64

The group problem was a red herring. I created a non-posix group which is why it didn't appear. I haven't been able to duplicate the hbac problem yet this morning.

I don't think this is a kerberos problem. There is zero activity in the LDAP server logs when I'm seeing these failures. I confirmed using ldapsearch from the client machine that the server is reachable and responds to requests.

Duplicating this is hit or miss, I can't force it. This morning I've reproduced it a couple of times. With sssd 1.1.1 it would fail 3 or 4 times and finally connect and work. With sssd 1.9.0 I've been unable to login for 10 minutes now after a dozen or so attempts.

As a goof I did my group test again, this time adding a posix group g2. I did a getent group g2 and got an immediate correct response. I was then able to log in past the hbac rule. I have no way of knowing if one change caused the other or not.

I actually do have an established LDAP connection:

tcp 0 0 tiger.greyoak.com:36086 lion.greyoak.com:ldap ESTABLISHED

Log of failed hbac request using sssd-1.1.90-0.2010043011gitfc28a2f.fc12.x86_64
sssd-hbac.log

Dupe of ticket #469

resolution: => duplicate
status: new => closed

Fields changed

rhbz: => 0

Fields changed

milestone: NEEDS_TRIAGE => void

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/1501

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.