Request to change MIT Kerberos behavior when principal is expired, deleted or password changed
Russ Allbery
eagle at eyrie.org
Fri Mar 7 19:45:12 EST 2014
Nico Williams <nico at cryptonector.com> writes:
> +1. No one has objected yet.
> The problem with applying this to password changes is that if you're
> logged in on multiple systems you'll have to kinit on each of them...
> *or* have SSH cascading credential delegation going. Now, if your
> cascading credential delegation clients are using timers based on ticket
> expiration... then your new tickets won't be forwarded soon enough.
> This could get annoying.
> Password changes are annoying enough as it is, so I could see someone
> objecting to that. Preemptively making this configurable seems like a
> win to me.
Yeah, I don't think we could enable the password change invalidation here.
It's a neat idea, and it's a clear win from a security perspective, but
it's one of those things that devilishly hard to explain to users. Most
users aren't even aware they *have* a Kerberos ticket cache; it's some
detail that software manages for them. So when it suddenly breaks, it's
hopelessly confusing to them.
--
Russ Allbery (eagle at eyrie.org) <http://www.eyrie.org/~eagle/>
More information about the Kerberos
mailing list