On Thu, 2012-02-23 at 12:59 -0700, Stephen John Smoogen wrote: > On 23 February 2012 12:28, Stephen Gallagher <sgallagh@xxxxxxxxxx> 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. >
Attachment:
signature.asc
Description: This is a digitally signed message part
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
