Hi Stephen,

Alright then - so if I understand correctly, I can have a situation where TGTs are generated with a short lifetime (say 7 days) but long renewable periods (say 6 months).

I can then configure sssd to renew Kerberos cache on the user's behalf every 7 days. It will work nicely for 6 months and then user will be forced to renew his cache manually (by entering the password).

Now what happens if I lock the account / fire the person in the mean time? KDC should refuse the renewal, right?
Thanks,

Ondrej

On 02/16/2012 03:40 PM, Stephen Gallagher wrote:
On Thu, 2012-02-16 at 15:31 +0100, Ondrej Valousek wrote:
Hi List,

Is it planned for sssd to allow it to renew user's Kerberos cache
in /tmp/krb5cc_XXXXXX automatically (i.e. much like what the lsass.exe
service does in Windows)?
For this to happen, we would need to cache user's plaintext password
in memory I know, but could be handy in some situations....
For the record, we have no plans to allow performing this action with a
stored plaintext password. This is insecure for many reasons (not least
of which is that it is bypassing security settings configured on the KDC
which may be used to guarantee that a human being re-authenticates at
least every so often).

If you want to effect this behavior, the easiest approach would be to
convince your KDC administrator to allow very long renewable periods
(such as several days) on the requested TGTs. Then you can use the much
safer renewable ticket approach I described in my other email.
_______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel