TGS granting

Derek Atkins derek at
Wed Oct 31 18:20:10 EDT 2018


The fact that the kerberized service itself is asking for refreshes isn't
important.  The proxy can cache the TGT and/or the service ticket on
behalf of the user session and can use that ticket for as long as it is
valid.. That service ticket can be valid for much longer than the
kerberized service will cache its session.  When that happens, the proxy
would re-submit the same service ticket with an updated authenticator
(proof-of-possession of the secret key in the ticket) to the kerberized

The proxy will only need to refresh the service ticket when *IT* expires,
which can be set at the KDC or by the proxy its acquisition.  It's not
unusual for tickets to have lifetimes on the order of 24 hours or more.

So the way I see this process:

1) User "logs in" to proxy and presents their kerberos credentials (or the
proxy already has them, somehow).

2) Proxy goes to KDC, obtains TGT and Service Ticket for Kerberized Service

3) Proxy uses service ticket for as long as required.

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

5) When the service ticket expires, the client session is destroyed and
only THEN would the proxy ask the user to re-authenticate.

Hope this helps!


On Wed, October 31, 2018 6:02 pm, moore moore wrote:
>  Thanks for reply and info.I follow you in relation to the TGT being
> required at the TGS on the KDC.So I think you are indicating that there
> is no short cut available.
> Just to note that the clients are not using kerberos. Hence the
> intermediate process on the proxy having a user enabled for delegation.
> The proxy can cache the service tickets ( it has sessions associated with
> the clients), but the kerberized server on the backend, will force re
> authentications (too) frequently by issuing of the 401s.
> btw, does it take multiple TGS_REQs/TGS_RSPs to establish a security
> context? Or should it happen with a single TGS_REQ/TGS_RSP?
> Thank you.
>     On Wednesday 31 October 2018, 16:00:50 GMT, Benjamin Kaduk
> <kaduk at> wrote:
>  On Wed, Oct 31, 2018 at 02:36:39PM +0000, moore moore wrote:
>> Hello,I hope I have the correct forum for some guidance.
>> I have the following scenario:
>> Clients(generally web based), linux proxy and windows server farm.The
>> proxy is configured with a user that is configured for kerberos
>> constrained delegation.A TGT is granted for this user with delegation
>> enabled.
>> TGS are also granted and everything works OK.
>> However I have a resource utilization problem on the proxy where the
>> windows servers are frequently requesting re authorization with 401
>> Negotiate.
>> This causes and intermediate process on the proxy to contact the KDC for
>> new TGS.
>> Is there a way for the intermediate process to generate service tickets
>> without having to go to the KDC? It already has the TGT.
>> Or is a round trip to the KDC ( Windows AD) always required to get
>> service tickets?
> The TGT is used to authenticate to the TGS so that the TGS can issue
> service tickets; the TGT alone is not enough to produce service tickets.
>> Due to the connection behavior, there are very many TGS_REQs on the
>> wire.
>> Is there any way to optimize this behavior and avoid so much traffic
>> back and forth to the KDC for TGS_REQ/TGS_RSP.
> Are the 401 Negotiates doing credential delegation or just authentication?
> For authentication the clients should be able to cache service tickets and
> reuse them, without need for a TGS exchange for every HTTP authentication.
> -Ben
> _______________________________________________
> krbdev mailing list             krbdev at

       Derek Atkins                 617-623-3745
       derek at   
       Computer and Internet Security Consultant

More information about the krbdev mailing list