Offline log in

[Sutton, Harry (GSSE)]

After getting sssd logins working yesterday (thanks again, Sumit), I was 
pleasantly surprised to find I was able to login this morning with my 
domain credentials from home /before/ I had established my VPN 
connection to the office. (I know I shouldn't have necessarily been 
surprised, that's the expected behavior, but I've been fiddling with 
this for weeks and only yesterday finally got things working as 'expected'.)

Before I made my VPN connection, I did a klist to see the cached 
credentials, and did a double-take when I saw the TGT:



At first I thought I was back in the U.S. Navy boot camp (which is where 
I was on December 31, 1969) but then I decided this timestamp might have 
been chosen intentionally to pre-date UNIX epoch time. But why go to all 
that trouble rather than just use the valid TGT I had received yesterday 
when I made a live, valid connection? Wasn't that cached, along with my 
authentication credentials?

Once I established my tunnel connection, I checked again, saw the same 
(old) TGT, so I logged out of the session (without dropping the tunnel 
connection) and when I logged back in I had a TGT dated today. I'm 
guessing (something I can test easily enough) that if I had waiting long 
enough before logging out and back in again, the TGT would have been 
re-issued correctly.

-- 
*Harry Sutton*
Global Solutions Support Engineering (GSSE)
GSD Customer Solution Center
Technology Services, Enterprise Group

[Stephen Gallagher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/11/2013 08:15 AM, Sutton, Harry (GSSE) wrote:
>  After getting sssd logins working yesterday (thanks again, Sumit),
>  I was pleasantly surprised to find I was able to login this morning
>  with my domain credentials from home /before/ I had established my
>  VPN connection to the office. (I know I shouldn't have necessarily
>  been surprised, that's the expected behavior, but I've been
>  fiddling with this for weeks and only yesterday finally got things
>  working as 'expected'.)
>  
>  Before I made my VPN connection, I did a klist to see the cached 
>  credentials, and did a double-take when I saw the TGT:
>  
>  
>  
>  At first I thought I was back in the U.S. Navy boot camp (which is
>  where I was on December 31, 1969) but then I decided this timestamp
>  might have been chosen intentionally to pre-date UNIX epoch time.
>  But why go to all that trouble rather than just use the valid TGT I
>  had received yesterday when I made a live, valid connection? Wasn't
>  that cached, along with my authentication credentials?
>   
Our default behavior on modern systems is actually to store the
kerberos credential cache in volatile storage (a tmpfs on Fedora).
This is intentional as a security precaution, as it means that on
reboot you need to have human intervention in order to gain network
access again. This can be changed in sssd.conf by setting the
krb5_ccachedir option to point to somewhere persistent.

We create that special cache file in order to play better with other
kerberos-enabled applications (such as krb5-auth-dialog) which would
otherwise try to create their own cache in a location that SSSD
couldn't be aware of. So we generate a cache file, populate it with
intentionally expired data and then establish the user's session with
the KRB5CCNAME environment variable set to point to it for the benefit
of those other kerberized apps.


>  Once I established my tunnel connection, I checked again, saw the
>  same (old) TGT, so I logged out of the session (without dropping
>  the tunnel connection) and when I logged back in I had a TGT dated
>  today. I'm guessing (something I can test easily enough) that if I
>  had waiting long enough before logging out and back in again, the
>  TGT would have been re-issued correctly.
>   

If this is a single-user machine, we recommend enabling the
(disabled-by-default) option krb5_store_password_if_offline (set it to
True). What this does is temporarily store your plaintext password in
the kernel keyring until SSSD detects that it has gone "online". This
may take as much as two minutes on some systems (though it may be
close to instantaneous when using VPN, as we monitor for changes in
the network and DNS resolver state as a cue to try reconnecting to
LDAP). Then the SSSD will kinit on your behalf and update that stale
cache.


Also, locking your screen and unlocking it with your password is a
less-invasive way to force a kinit as well, rather than logging out
and back in.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.13 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlFmr0oACgkQeiVVYja6o6NDaACfd1xBcHZnvuxhR4QlN5ZBUBVC
> 01YAoKiOvKy995xWBY6opqCuC0dz7HN0
> =tn+V
> -----END PGP SIGNATURE-----

[Sutton, Harry (GSSE)]

On 04/11/2013 08:40 AM, Stephen Gallagher wrote:
>  Our default behavior on modern systems is actually to store the
>  kerberos credential cache in volatile storage (a tmpfs on Fedora).
>  This is intentional as a security precaution, as it means that on
>  reboot you need to have human intervention in order to gain network
>  access again. This can be changed in sssd.conf by setting the
>  krb5_ccachedir option to point to somewhere persistent.
>
>  We create that special cache file in order to play better with other
>  kerberos-enabled applications (such as krb5-auth-dialog) which would
>  otherwise try to create their own cache in a location that SSSD
>  couldn't be aware of. So we generate a cache file, populate it with
>  intentionally expired data and then establish the user's session with
>  the KRB5CCNAME environment variable set to point to it for the benefit
>  of those other kerberized apps.
>  
That makes sense, I was overlooking the security vulnerability that 
caching a (potentially) still valid credential would present.
>  If this is a single-user machine, we recommend enabling the
>  (disabled-by-default) option krb5_store_password_if_offline (set it to
>  True). What this does is temporarily store your plaintext password in
>  the kernel keyring until SSSD detects that it has gone "online". This
>  may take as much as two minutes on some systems (though it may be
>  close to instantaneous when using VPN, as we monitor for changes in
>  the network and DNS resolver state as a cue to try reconnecting to
>  LDAP). Then the SSSD will kinit on your behalf and update that stale
>  cache.
>
>
>  Also, locking your screen and unlocking it with your password is a
>  less-invasive way to force a kinit as well, rather than logging out
>  and back in. 
Both good suggestions, thanks.

     /Harry

[Sumit Bose]

On Thu, Apr 11, 2013 at 08:15:41AM -0400, Sutton, Harry (GSSE) wrote:
>  After getting sssd logins working yesterday (thanks again, Sumit), I
>  was pleasantly surprised to find I was able to login this morning
>  with my domain credentials from home /before/ I had established my
>  VPN connection to the office. (I know I shouldn't have necessarily
>  been surprised, that's the expected behavior, but I've been fiddling
>  with this for weeks and only yesterday finally got things working as
>  'expected'.)
>  
>  Before I made my VPN connection, I did a klist to see the cached
>  credentials, and did a double-take when I saw the TGT:
>  
>  
>  
>  At first I thought I was back in the U.S. Navy boot camp (which is
>  where I was on December 31, 1969) but then I decided this timestamp
>  might have been chosen intentionally to pre-date UNIX epoch time.
>  But why go to all that trouble rather than just use the valid TGT I
>  had received yesterday when I made a live, valid connection? Wasn't
>  that cached, along with my authentication credentials?
>  
>  Once I established my tunnel connection, I checked again, saw the
>  same (old) TGT, so I logged out of the session (without dropping the
>  tunnel connection) and when I logged back in I had a TGT dated
>  today. I'm guessing (something I can test easily enough) that if I
>  had waiting long enough before logging out and back in again, the
>  TGT would have been re-issued correctly. 
I think krb5_store_password_if_offline (see man sssd-krb5) is the option
you are looking for. About the strange date, sssd creates and empty
credential cache with UNIX epoch time to allow other desktop application
which tries to re-new the Kerberos ticket start working. I think that
you see December 31 is due to your timezone.

HTH

bye,
Sumit

>  
>  -- 
>  *Harry Sutton*
>  Global Solutions Support Engineering (GSSE)
>  GSD Customer Solution Center
>  Technology Services, Enterprise Group 


>  _______________________________________________
>  sssd-users mailing list
>  sssd-users(a)lists.fedorahosted.org
>  https://lists.fedorahosted.org/mailman/listinfo/sssd-users

[Sutton, Harry (GSSE)]

On 04/11/2013 08:42 AM, Sumit Bose wrote:
>  I think krb5_store_password_if_offline (see man sssd-krb5) is the
> option
>  you are looking for. About the strange date, sssd creates and empty
>  credential cache with UNIX epoch time to allow other desktop application
>  which tries to re-new the Kerberos ticket start working. I think that
>  you see December 31 is due to your timezone.
>
>  HTH
>
>  bye,
>  Sumit
>
>  
That fits - I'm at UTC -5 (US East Coast on Daylight Saving Time,) and 
the timestamp was 19:00.

     /Harry