Unless things have changed, the KDC doesn't check for account lock if the tgt is valid. There's a thread from a couple years back where I asked about this and then patched it, but I haven't submitted patches for the current revision. I need to do this at some point. Or maybe it got fixed?
Chris On Jul 31, 2014 3:15 PM, "Roland C. Dowdeswell" <[email protected]> wrote: > On Thu, Jul 31, 2014 at 04:34:42PM -0500, Nico Williams wrote: > > > > > In general Kerberos doesn't need a revocation system because ticket > > lifetimes should be short enough. > > You can get many of the benefits of a revocation system by simply > vending service tickets with a shorter lifetime than the TGT used > to obtain them. If you, e.g. vend service tickets with a 15 minute > lifetime, then the client will need to contact the KDC once every > 15 minutes to continue to connect to a service. The KDC, of course, > will validate that the client's account has not been locked at this > point. > > > Within a realm it's often the case that other methods are used for > > revocation (e.g., lock the _account_, which will generally replicate > > with less latency than tickets will expire). > > Right and by using different lifetimes for service tickets as their > TGT, you can break apart the ``check that the user knows their > passwd'' check from the ``check that the account is still valid'' > check. > > > Across realms is where things get interesting. A TGS would have to > > track the x-realm ticket vending it has done so that it could > > selectively propagate revocation notifications to those realms that > > ought to see them. Otherwise the system can't scale. In practice > > cross-realm TGTs tend to be shorter lived than local TGTs, and for > > this reason. > > Simply issue 15 minute xrealm TGTs. Sorted. > > > A not-before timestamp in tickets might be useful, but not sufficient. > > A revocation system would have to involve an actual service sourcing > > and propagating revocation notifications to all those services that > > might need them, which in turn requires KDCs to keep track of all > > extant (as yet not expired) tickets vended. > > > > IMO it's worth exploring, but how worthwhile this is will depend on > > how common it is for people to run with a) very long-lived local TGTs > > and no other revocation scheme in place, and/or b) very long-lived > > cross-realm TGTs. Assuming the worst, then it's worthwhile, of > > course. > > > > In a way such a system would scale better than revocation does for > > PKI, where CRLs regularly go unchecked, and where OCSP responses have > > Kerberos ticket-like lifetimes. > > There is a trade-off here. Using very short service and xrealm > tickets puts the burden on the client to obtain new credentials > frequently whereas a revocation list places the burden on the server > to accept a feed of revocations. Each has its pros and cons. One > main pro of using short non-TGT ticket lifetimes is that it is > already possible without writing new code. > > -- > Roland Dowdeswell http://Imrryr.ORG/~elric/ > ________________________________________________ > Kerberos mailing list [email protected] > https://mailman.mit.edu/mailman/listinfo/kerberos > ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
