Comment 1 for bug 1039151

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.