Created attachment 807299[details]
My sssd config file
Description of problem:
Cannot log in with LDAP account through GDM or TTY if not connected to LAN.
Version-Release number of selected component (if applicable):
sssd-proxy-1.11.1-1.fc19.x86_64
sssd-ipa-1.11.1-1.fc19.x86_64
sssd-common-1.11.1-1.fc19.x86_64
sssd-ad-1.11.1-1.fc19.x86_64
sssd-client-1.11.1-1.fc19.i686
sssd-client-1.11.1-1.fc19.x86_64
sssd-krb5-common-1.11.1-1.fc19.x86_64
sssd-1.11.1-1.fc19.x86_64
sssd-ldap-1.11.1-1.fc19.x86_64
python-sssdconfig-1.11.1-1.fc19.noarch
sssd-common-pac-1.11.1-1.fc19.x86_64
sssd-krb5-1.11.1-1.fc19.x86_64
How reproducible:
By virtue of not having connectivity to LDAP server, login fails.
Steps to Reproduce:
1.Log in with LDAP account while on lan or VPN.
2.Reboot.
3.Unplug network cable or otherwise go offline.
4.Try to use LDAP account.
5.See fail.
Actual results:
Login failure
Expected results:
Login success
Additional info:
I use LDAP user info and Kerberos auth. If I log into my VPN as a local user, and ssh user@localhost, I can then continue with using my LDAP account. It is more than possible that I am stupid, but I have RTFM, and I'm still flummoxed. Let me know what you need, if anything.

(In reply to Dmitri Pal from comment #1)
> Seems like same as https://bugzilla.redhat.com/show_bug.cgi?id=1015089
> Can you please verify that it is in fact the same issue?
No, I don't think the symptoms look alike at all, actually.
Jason, first of all: I assume you have
cache_credentials = True
in the [domain/DOMAINNAME] section of /etc/sssd/sssd.conf?
It sounds to me like something is failing during offline authentication, which could be any of a number of things. The first thing to check would be /var/log/secure at the time of the authentication attempt. Look for lines involving "pam_sss" and include them here.
If that line says something like
pam_sss(sshd:auth): received for user username: 7 (Authentication failure)
Then this probably means it didn't accept the password.
If you see
pam_sss(sshd:auth): received for user username: 4 (System Error)
then it means there's a bug in SSSD. In this case, please add the line
debug_level = 7
to both the [pam] and [domain/DOMAINNAME] sections of sssd.conf, restart SSSD and perform the login attempt again, then attach /var/log/sssd/sssd_pam.log and /var/log/sssd/sssd_DOMAINNAME.log to this ticket as a private attachment.

This line from the logs:
(Fri Oct 4 06:08:32 2013) [sssd[be[domain.com]]] [parse_krb5_child_response] (0x1000): child response [0][3][37].
Says the krb5_child was able to prep the ccache for an offline login. Is there any chance you could provide logs from both the domain section and the pam section with a higher debug_level?

(In reply to Jakub Hrozek from comment #6)
> Says the krb5_child was able to prep the ccache for an offline login. Is
> there any chance you could provide logs from both the domain section and the
> pam section with a higher debug_level?
No problem! I should be in a position to see this error tomorrow morning. I will test after noon, my time. First, I will crank up the logging to all sections to 0x4000, unless you'd like me to specify a higher number.

0x4000 is not actually a higher number. The log levels (when specified in hex) are tricky to understand. They present a mask so we can turn some levels on and some off. 0x4000 would *only* show the low-level tracing.
It would be much easier to specify the decimal version, which amounts to "this level and all that come before it".
I think you probably want
debug_level = 7
(8 and 9 are pretty noisy)

It happened again this morning, not long after first log in. I will attach logs in just a moment. Here's what I was doing:
0. removed bonding module and rebuilt initramfs
X. (could this logon issue be caused by a kernel upgrade?)
1. powered off
2. undock (network on dock)
3. powered on
4. log into GDM (x4)
5. no success
6. docked
7. no success, first time
8. logged in successfully

Jason, when uploading the attachment, there is a checkbox at the bottom just above submit called "Privacy". This restricts visibility of the attachment to the private_comments group. (Essentially Red Hat engineers only).

(In reply to Stephen Gallagher from comment #15)
> Jason, when uploading the attachment, there is a checkbox at the bottom just
> above submit called "Privacy". This restricts visibility of the attachment
> to the private_comments group. (Essentially Red Hat engineers only).
Stephen, don't have that option when uploading. Would you mark the second one for me?

Jason, I assume it's Active Directory on the server side?
Can you put:
ldap_referrals = False
to the [domain] section and restart the SSSD? It's probably not the issue that's been hitting you but should be set anyway..I've seen a number of referrals followed in the sssd logs and disabling referral chasing is the recommended thing to do.

There is definitely something fishy going on. There is one authentication request at 05:52:13 that succeeds:
(Wed Oct 9 05:52:13 2013) [sssd[pam]] [sysdb_cache_auth] (0x0100): Hashes do match!
And then another one for the same user:
(Wed Oct 9 07:05:18 2013) [sssd[pam]] [sysdb_cache_auth] (0x0100): Cached credentials not available.
I'm just speculating so far, but I wonder if a search on the backend side could have succeeded but returned nothing so that we'd remove the user entry? I can't think of another reason the attribute would get lost.

We are using AD for LDAP. I set the referrals section (we have that in or RHEL environment, from which i copied).
For background, I had been on the network when I started my laptop at the 5:52. At 7:05 I had unplugged, it failed and then plugged back in. Yesterday, everything had worked perfectly. So, I know its working, but there is something keeping it from working consistently. I had put in my password in wrongly one time. Could that have triggered that error? Or, is that responding to the pam_unix failure?
Oct 9 05:52:03 cosi001n gdm-password]: pam_unix(gdm-password:auth): authentication failure; logname=(unknown) uid=0 euid=0 tty=:0 ruser= rhost= user=LDAPUSER
Oct 9 05:52:03 cosi001n gdm-password]: pam_sss(gdm-password:auth): authentication failure; logname=(unknown) uid=0 euid=0 tty=:0 ruser= rhost= user=LDAPUSER
Oct 9 05:52:03 cosi001n gdm-password]: pam_sss(gdm-password:auth): received for user LDAPUSER: 7 (Authentication failure)
Oct 9 05:52:13 cosi001n gdm-password]: pam_unix(gdm-password:auth): authentication failure; logname=(unknown) uid=0 euid=0 tty=:0 ruser= rhost= user=LDAPUSER
Oct 9 05:52:13 cosi001n gdm-password]: pam_sss(gdm-password:auth): authentication success; logname=(unknown) uid=0 euid=0 tty=:0 ruser= rhost= user=LDAPUSER
Oct 9 05:52:13 cosi001n gdm-password]: pam_unix(gdm-password:session): session opened for user LDAPUSER by (unknown)(uid=0)
Oct 9 05:52:14 cosi001n gdm-launch-environment]: pam_unix(gdm-launch-environment:session): session closed for user gdm

I logged on this morning with my account thinking my problem was solved. However, I couldn't even log in until I was on my VPN and had restarted the sssd service. I am about to upload all of the logs to you.