Headsup! krb5 ccache defaults are changing in Rawhide

[Stephen Gallagher]

On Thu, 2012-02-23 at 12:59 -0700, Stephen John Smoogen wrote:
> On 23 February 2012 12:28, Stephen Gallagher <sgallagh at redhat.com> wrote:
> > Dear fellow developers,
> >
> > with the upcoming Fedora 18 release (currently Rawhide) we are going to
> > change the place where krb5 credential cache files are saved by default.
> >
> > The new default for credential caches will be the /run/user/<username>
> > directory.
> 
> I am going to ask something probably obvious but not what I could
> easily google. The sssd can be configured to cache tickets for a
> weekend or such in this case. The usage we usually ran into was:
> 
> 1) Users can only log into laptops if able to communicate with AD/KRB
> servers or if a valid local ticket still existed.
> 2) User would turn off laptop and go home.
> 3) User would work from home and get a refreshed/new ticket when they
> got the VPN up. [If they didn't.. then they could not log in again
> after the ticket expired.]
> 

This is just plain wrong. If that was happening, it was a bug in SSSD.
If we can't reach the Kerberos server, we'd authenticate against the
local cache (assuming that cached_credentials = True in sssd.conf). If
they also have krb5_store_password_if_offline = True, then the
credentials should automatically be updated when the VPN comes up as
well. (In the interim, we generate a fake credential cache file that
contains tickets that expired at the start of the epoch, so that
krb5-auth-dialog or manual kinit and the like will behave
appropriately).

The current validity status of the Kerberos ticket is completely
irrelevant to successful login. For the record, I've been
using /run/user/sgallagh/krb5cc for over a month now, and I've never
once had an issue authenticating with my cached credentials while
logging in at home, nor have I had an issue with the automatic deferred
kinit updating my tickets when I VPN in.

> In the Linux side the existance of a ticket in /tmp allowed this to
> work... but not sure how it would work in current environment.
> 
> The above is probably "broken" in various ways that I don't know.. but
> was how a couple large work places had been set up.
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20120223/40cc9d61/attachment.sig>