SSSD generates invalid Kerberos ticket at login

[musicalvegan0]

Ubuntu 12.04.1
sssd 1.8.2-0ubuntu1
Arch i386

When SSSD is configured for krb5 auth and a user successfully logs in, the following ticket is generated in /tmp/krb5cc_UID_XXXXXX:
klist -c /tmp/krb5cc_UID_XXXXXX
Default principal: <email address hidden>

Valid starting Expires Service principal
31/12/1969 19:00 31/12/1969 19:00 <email address hidden>

The expected outcome is receive a Kerberos ticket with a valid starting and stopping date.

After some experimentation, the issue may be related to the credential cache as deleting the bad ticket, deleting the SSSD cache, and restarting the sssd service seems to produce a valid ticket:
service sssd stop
rm /tmp/krb5cc_UID_XXXXXX
rm -rf /var/lib/sss/db/*
service sssd start
<user log in successful>
klist -c /tmp/krb5cc_UID_XXXXXX
Default principal: <email address hidden>

Valid starting Expires Service principal
20/08/2012 13:49 20/08/2012 23:49 <email address hidden>
 renew until 20/08/2012 23:49

Specifying krb5_* options in sssd.conf seems to have no effect on the outcome of the ticket.

Obviously, this bug creates problems for applications and services that require a valid Kerberos ticket such as Kerberized NFS mounts.

[Stephen Gallagher (stephen-gallagherhome)]

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.

[musicalvegan0 (musicalvegan0)]

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?

[musicalvegan0 (musicalvegan0)]

Better question:

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

[musicalvegan0 (musicalvegan0)]

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.

[Stephen Gallagher (stephen-gallagherhome)]

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!

[bog (martaina)]

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

[bog (martaina)]

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