SSSD generates invalid Kerberos ticket at login

You are actually seeing intentional behavior here. What is happening is that the initial login is occurring while SSSD is operating in "offline" mode. Usually this happens when some application makes a request of SSSD during startup before it has access to the remote LDAP server. As a result, it switches into offline operation for two minutes. If you waited two minutes before logging in, you would probably have your authentication transmitted to the KDC and would receive a valid ticket.

The reason for the obviously expired ticket is so that the credential cache is still created. Without doing this, utilities like krb5-auth-dialog would not be able to track the credentials at session login.

There's another way you can mitigate this (designed mainly for the cases where your LDAP/KDC is only available behind VPNs, but will also work for this use-case). You can set the option "krb5_store_password_if_offline = True" in the [domain/DOMAINNAME] section of sssd.conf. What this does is store your plaintext password securely in the kernel keyring until the SSSD detects that you have regained access to the KDC. At that time, SSSD will authenticate on your behalf and update the credential cache with your valid TGT.

We don't enable this option by default because it does have a limited risk of exposing your password to the root user on the system (mitigated as best we can with kernel keyring permissions), but if you have exclusive access to your machine, it should be pretty much safe.

Otherwise, you can just get your TGT yourself by running kinit (or unlocking your screen) after a couple minutes have passed.

Stephen,

That explanation makes perfect sense, however, it does create some problems.

I discovered this behavior when testing Kerberized NFSv4 shares for users' home directories.

When a user logs in and attempts to access their home directory which is hosted on a Kerberized NFS share, the user is unable to login, often because the login process hangs while rpc.gssd throws some errors about having a corrupted or expired ticket. Therefore, a user doesn't even get a chance to execute kinit because they can't login (I admit that the hanging of the login process is more of an NFS/gssd bug as opposed to SSSD). I feel that, even if the login didn't freeze, having a user execute a command and type their password again before getting access to their home data is messy and frustrating.

Also, storing the plaintext password in the kernel keyring in a multi-user environment seems sub-optimal for security.

Would disabling offline mode solve my problem as a workaround?

Better question:

Is there a way to disable offline mode in SSSD at all? Perhaps by not caching credentials?

I can also confirm that using krb5_store_password_if_offline = true does not allow a user to access their Kerberized home directory upon initial login.

Further, setting cache_credentials = false prevents authentication completely after a reboot.

I apology for these noisy posts.

I understand your issue. Right now, your best bet is to operate with 'cache_credentials = False', which will at least deny access completely until SSSD has re-established connection to the LDAP and KDC servers. As I said above, we always operate in offline mode for a period of 1-2 minutes after failing to connect to the LDAP server.

Upon review of this bug, I agree that we should modify this behavior in the case where cache_credentials = False so that we will always bypass the offline timeout in the event of a PAM conversation request. I've opened the upstream ticket https://fedorahosted.org/sssd/ticket/1493 to track this.

Thanks for the bug report!

This was my workaround for the problem. I made lightdm wait until we have network.

Here are the skripts:

/etc/init/networkdelay.conf :

description "wait for IP to be there"

#emits networkdelay

start on (net-device-up IFACE!=lo
        and local-filesystems)

#start on (((starting lightdm or starting kdm) or starting xdm) or starting lxdm)
start on (starting lightdm
        or starting kdm
        or starting xdm
        or starting lxdm)

task

script
        exec /usr/sbin/network-ok
end script

/usr/sbin/network-ok:

#!/bin/sh
LOG=/tmp/network-diag
rm $LOG
#LOG=/dev/null
#touch $LOG
MAXWAIT=60
T0=`cut -f1 -d. /proc/uptime`

while (( test $(($T0+$MAXWAIT)) -gt $(cut -f1 -d. /proc/uptime) ))
do
 date >> $LOG
 pidof lightdm >> $LOG
 #GW=`ip ro list default |head -1 |cut -d " " -f 3`
 GW=`ip -4 ro list 0.0.0.0/0 | cut -d " " -f 3`
# ethtool eth0 >> $LOG
 test -n "$GW" && ping -c1 -w1 $GW >> $LOG 2>&1 && break
 sleep 1
done

I also opened a bug report for lightdm : Bug #1291278