Request to change MIT Kerberos behavior when principal is expired, deleted or password changed

[Jason Edgecombe]

On 03/07/2014 06:16 PM, Greg Hudson wrote:
> On 03/07/2014 05:17 PM, Edgecombe, Jason wrote:
>> I don't see how anyone can object to rejecting requests for expired or deleted principals.
> I don't think anyone has.  In the past I have mentioned performance as a
> possible issue, but it turns out we have been looking up the client
> entry for most TGS requests since 1.7, so that's not a concern.
>
> The change may not be a trivial one to make safely, because there are so
> many edge cases in modern TGS request processing.
>
> Be aware that:
>
> * We cannot generally do these checks for cross-realm TGS requests.
>
> * The KDC cannot revoke already-issued service tickets.
>
I accept your bullet points, but the current situation is much worse. In 
the current MIT implementation, TGTs are good for the entire *renewable* 
lifetime, and you can't block that TGT from getting new service tickets 
or renewing the TGT so long as the renewable deadline has not been 
reached and the normal lifetime has not expired.

Even if I have tickets with an 8 hour lifetime and a 7 day renewable 
lifetime, MIT krb will happily keep issuing service tickets and renewing 
the TGT until the 7 days has passed. This is not desirable when a user 
leaves the organization on unhappy terms.

I understand that you can't block service tickets that were already 
issued, but I can limit the damage by having short lifetimes and longer 
renewable lifetimes. As it stands right now, I can only maintain a short 
time time window by keeping the renewable lifetime short.

Jason