I have seen this. It is usually the case when the VPN drops in between the last two times SSSD talks to server or you change networks. For example you were on the netweork that had direct access to the server and then close the lid, suspend and go to a place like Whole Foods or Panera and try to resume there. The network connection will be established pretty quickly if you go there from time to time and have non expired certs but SSSD might be confused that it is online and try server with fail over before it will give up and go offline.
Anyways to troubleshoot the issue we would need SSSD logs. I suspect the devug_level should be at least 6 to see what is going on.

Dmitri,

I attached the logs in the tar file I uploaded when I created the bug.  Let me know if you need something additional.

Mason

I have also seen this when the VPN drops while my screen is locked from prolonged inactivity or has been suspended for an extended period of time.

I haven't been able to reproduce the issue yet, but the investigation of the logs revealed a possible cause, which is our improper handling of DNS timeouts.

----------------------------------------------
(Thu Jul 28 13:41:20 2011) [sssd[be[redhat.com]]] [set_server_common_status] (4): Marking server 'kerberos.rdu.redhat.com' as 'resolving name
'
(Thu Jul 28 13:41:21 2011) [sssd[be[redhat.com]]] [check_fd_timeouts] (9): Checking for DNS timeouts
(Thu Jul 28 13:41:25 2011) [sssd[be[redhat.com]]] [check_fd_timeouts] (9): Checking for DNS timeouts
(Thu Jul 28 13:41:30 2011) [sssd[be[redhat.com]]] [check_fd_timeouts] (9): Checking for DNS timeouts
(Thu Jul 28 13:41:31 2011) [sssd[be[redhat.com]]] [check_fd_timeouts] (9): Checking for DNS timeouts
(Thu Jul 28 13:41:36 2011) [sssd[be[redhat.com]]] [check_fd_timeouts] (9): Checking for DNS timeouts
----------------------------------------------

Our internal resolver library treats its timeout parameter as per-server. I suspect that in the above example, /etc/resolv.conf contained multiple records and resolver waited 5 seconds for every one of them. The same happened for the second server configured in fail over, doubling the total time.

This does not happen if the DNS server is down or unreachable, because the resolver would immediatelly detect that it can't connect and fail over.

I would like to try to reproduce the issue to be sure but I think we need to have a mechanism to cancel the resolving after the timeout and don't rely on the resolver library timeouts.

    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
No documentation needed

Verified with sssd-1.8.0-23.el6 that there is an improvement of ~30 seconds with the steps below:

Verification steps:

1. Setup bind dns on nameserver1 and nameserver2. Write a iptables rule to drop packets to port 53 on nameserver1.
2. Resolve hosts ldap.example.com and krb.example.com in the bind server.
3. On the client machine, in /etc/resolv.conf add:
   nameserver nameserver1
   nameserver nameserver2
3. In sssd.conf, the domain section is:
[domain/LDAP-KRB5]
id_provider = ldap
ldap_uri = ldap://invalid1.example.com,ldap://ldap.example.com
ldap_search_base = dc=example,dc=com
debug_level = 0xFFF0
auth_provider = krb5
krb5_server = invalid2.example.com,krb.example.com
krb5_realm = EXAMPLE.COM
4. Perform a auth.


Using sssd-1.5.1-66.el6_2.3:

# time ssh -l puser1 localhost
puser1@localhost's password: 
Last login: Fri Apr 27 13:37:05 2012 from localhost
-sh-4.1$ logout
Connection to localhost closed.

real	0m55.702s
user	0m0.007s
sys	0m0.039s


Using sssd-1.8.0-23.el6:

# time ssh -l puser1 localhost
puser1@localhost's password: 
Last login: Wed Apr 25 20:51:01 2012 from localhost
-sh-4.1$ logout
Connection to localhost closed.

real	0m23.047s
user	0m0.012s
sys	0m0.041s

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2012-0747.html