TGS granting

moore moore moore_chestnut at
Wed Oct 31 18:02:00 EDT 2018

 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.


More information about the krbdev mailing list