derek at ihtfp.com
Mon Nov 5 10:56:15 EST 2018
moore moore <moore_chestnut at yahoo.ie> writes:
> This is really helpful and makes alot of sense. Thank you for the detailed
> So in relation to:
> "4) If the service requests updated authentication (401) the proxy can
> refresh by re-running the Application authentication protocol using the
> cached service ticket. This can continue until the service ticket
> By "Application authentication protocol", do you mean TGS_REQ/RSP to the KDC?
No, I mean the AP_REQ/AP_REP between the Kerberos Client and the
> On the proxy, there is an application process ( using the kerberos lib) and
> the TGT is cached in kerberos credential cache. All this is fine.
> The service ticket is cached in an application level process.
Right, that would be caching the TGS_REQ/TGS_REP from the KDC. This
caching should be valid for ~24 hours, depending on how long the service
ticket is valid for.
> But I get very little use out of the cached service ticket, due to the demand
> and frequency of the 401s.
> When the 401 happens, ( in relation to your point 4), a series of TGS_REQ/RSP
> result on the wire between proxy and KDC. If I just use the cached ticket
> here, then it is just a crazy loop of 401s. That's why application process
> goes to KDC for new service ticket, which the kerberized service will accept,
> but then will quickly issue 401s again, thus resulting in having to go back to
> KDC again for new service ticket.
Have you verified that the service ticket is still valid?
Is there a time skew between the proxy (kerberos client) and the service?
> Is this the correct and only way for the proxy to "refresh" the service
No, you should be able to re-use the Service Ticket and just issue a new
AP_REQ/AP_REP between the proxy and the service. Unless the problem is
that the proxy is caching *THIS* -- in which case yes, you're kind of
screwed. Note that the AP_REQ/AP_REP is between the client and service,
and NOT with the KDC, so there is no reason that the client would need
to cache this.
> Thank you.
Derek Atkins 617-623-3745
derek at ihtfp.com www.ihtfp.com
Computer and Internet Security Consultant
More information about the krbdev