TGS granting

[moore moore]

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?
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.
Appreciate any guidance.

Thank you.






_______________________________________________
krbdev mailing list ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

[Benjamin Kaduk]

Post by moore moore
Hello,I hope I have the correct forum for some guidance.
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.

Post by moore moore
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 ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

[moore moore]

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.

Post by moore moore
Hello,I hope I have the correct forum for some guidance.
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.

Post by moore moore
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 ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

[Derek Atkins]

Hi,

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
service.

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
expires.

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!

-derek

Post by moore moore
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

Post by moore moore
Hello,I hope I have the correct forum for some guidance.
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.

Post by moore moore
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
_______________________________________________
https://mailman.mit.edu/mailman/listinfo/krbdev

[moore moore]

This is really helpful and makes alot of sense. Thank you for the detailed info.
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
expires."
By "Application authentication protocol", do you mean TGS_REQ/RSP to the KDC?
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.
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.

Is this the correct and only way for the proxy to "refresh" the service ticket?

Thank you.


On Wednesday 31 October 2018, 22:20:21 GMT, Derek Atkins <***@ihtfp.com> wrote:

Hi,

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
service.

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
expires.

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!

-derek

  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

Post by moore moore
Hello,I hope I have the correct forum for some guidance.
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.

Post by moore moore
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
_______________________________________________
https://mailman.mit.edu/mailman/listinfo/krbdev

[Derek Atkins]

Post by moore moore
This is really helpful and makes alot of sense. Thank you for the detailed info.
"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
expires."
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
Kerberized Server.

Post by moore moore
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.

Post by moore moore
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?

Post by moore moore
Is this the correct and only way for the proxy to "refresh" the service ticket?

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.

Post by moore moore
Thank you.

-derek

[moore moore]

Hello Derek,Thanks again for the helpful information..
Time skew is not present and the service ticket is cached.

OK, so at the moment, everytime there is a 401 from the kerberised windows server, the application process (on the proxy), goes to the KDC.
In wireshark, this always shows as a TGS-REQ/TGS-RSP
I never see a AP-REQ/AP-RSP in the trace/wireshark.BUT, but looking the kerberos library logs, I see it mentioned there.And then I checked tcpdump and I see AP-REQ as a value in some of the TGS-REQs.

Sample kerb log below.

Here there is
- AS-REQ and pre auth requested for ***@test.com user.
- AS-REQ and RSP for ***@test.com user.
- Sample TGS-REQ/RSP for ***@test.com ( can see AP-REQ) in log.
This is between proxy and KDC.So not sure, if I can get some data/token from this? and use between proxy and service.Which is over HTTP SPNEGO.

Is the sample code/api documentation you could refer me to so I could try understand how to build and use the AP-REQ?
Thank you for your time.


[14791] 1538167075.224560: Getting initial credentials for ***@test.com
[14791] 1538167075.225189: Looked up etypes in keytab: rc4-hmac
[14791] 1538167075.225577: Sending request (177 bytes) to TEST.COM
[14791] 1538167075.225915: Resolving hostname 172.21.162.211
[14791] 1538167075.226408: Sending initial UDP request to dgram 172.21.162.211:88
[14791] 1538167075.227366: Received answer (214 bytes) from dgram 172.21.162.211:88
[14791] 1538167075.228299: Response was not from master KDC
[14791] 1538167075.228471: Received error from KDC: -1765328359/Additional pre-authentication required
[14791] 1538167075.228653: Processing preauth types: 16, 15, 19, 2
[14791] 1538167075.228829: Selected etype info: etype rc4-hmac, salt "", params ""
[14791] 1538167075.229021: Retrieving ***@test.com from FILE:/etc/krb5.keytab (vno 0, enctype rc4-hmac) with result: 0/Success
[14791] 1538167075.229146: AS key obtained for encrypted timestamp: rc4-hmac/2163
[14791] 1538167075.229309: Encrypted timestamp (for 1538167075.859690): plain 301AA011180F32303138303932383230333735355AA10502030D1E2A, encrypted 717BCF6554C1F514AB6D86FB08D00E9BEA7EF1B56C6996DA76E0AB5D9812D5E0C4233E6DC88A7EEA6582FA5FDC22ADB86F95D178
[14791] 1538167075.229428: Preauth module encrypted_timestamp (2) (real) returned: 0/Success
[14791] 1538167075.229520: Produced preauth for next request: 2
[14791] 1538167075.229625: Sending request (251 bytes) to TEST.COM
[14791] 1538167075.229750: Resolving hostname 172.21.162.211
[14791] 1538167075.229923: Sending initial UDP request to dgram 172.21.162.211:88
[14791] 1538167075.230849: Received answer (98 bytes) from dgram 172.21.162.211:88
[14791] 1538167075.231488: Response was not from master KDC
[14791] 1538167075.231613: Received error from KDC: -1765328332/Response too big for UDP, retry with TCP
[14791] 1538167075.231736: Request or response is too big for UDP; retrying with TCP
[14791] 1538167075.231832: Sending request (251 bytes) to TEST.COM (tcp only)
[14791] 1538167075.231927: Resolving hostname 172.21.162.211
[14791] 1538167075.232095: Initiating TCP connection to stream 172.21.162.211:88
[14791] 1538167075.232374: Sending TCP request to stream 172.21.162.211:88
[14791] 1538167075.233225: Received answer (1548 bytes) from stream 172.21.162.211:88
[14791] 1538167075.233701: Response was not from master KDC
[14791] 1538167075.233829: Salt derived from principal: TEST.COMproxy
[14791] 1538167075.233933: AS key determined by preauth: rc4-hmac/2163
[14791] 1538167075.234083: Decrypted AS reply; session key is: rc4-hmac/FAF6
[14791] 1538167075.234202: FAST negotiation: unavailable
[14791] 1538167075.234328: Initializing FILE:/tmp/krb5cc_0 with default princ ***@test.com
[14791] 1538167075.234524: Removing ***@test.com -> krbtgt/***@TEST.COM from FILE:/tmp/krb5cc_0
[14791] 1538167075.234629: Storing ***@test.com -> krbtgt/***@TEST.COM in FILE:/tmp/krb5cc_0
[14791] 1538167075.234885: Storing config in FILE:/tmp/krb5cc_0 for krbtgt/***@TEST.COM: pa_type: 2
[14791] 1538167075.235039: Removing ***@test.com -> krb5_ccache_conf_data/pa_type/krbtgt\/TEST.COM\@***@X-CACHECONF: from FILE:/tmp/krb5cc_0
[14791] 1538167075.235143: Storing ***@test.com -> krb5_ccache_conf_data/pa_type/krbtgt\/TEST.COM\@***@X-CACHECONF: in FILE:/tmp/krb5cc_0
[14791] 1538167075.241199: Getting credentials ***@TEST.COM -> ***@test.com using ccache FILE:/tmp/krb5cc_0
[14791] 1538167075.241446: Retrieving ***@TEST.COM -> ***@test.com from FILE:/tmp/krb5cc_0 with result: -1765328243/Matching credential not found
[14791] 1538167075.241571: Getting credentials ***@test.com -> krbtgt/***@TEST.COM using ccache FILE:/tmp/krb5cc_0
[14791] 1538167075.241755: Retrieving ***@test.com -> krbtgt/***@TEST.COM from FILE:/tmp/krb5cc_0 with result: 0/Success
[14791] 1538167075.241886: Get cred via TGT krbtgt/***@TEST.COM after requesting ***@test.com (canonicalize on)
[14791] 1538167075.241986: Generated subkey for TGS request: rc4-hmac/86EA
[14791] 1538167075.242096: etypes requested in TGS request: aes256-cts, aes128-cts, des3-cbc-sha1, rc4-hmac, camellia128-cts, camellia256-cts
[14791] 1538167075.242257: Encoding request body and padata into FAST request
[14791] 1538167075.242433: Sending request (2176 bytes) to TEST.COM
[14791] 1538167075.242534: Resolving hostname 172.21.162.211
[14791] 1538167075.242729: Initiating TCP connection to stream 172.21.162.211:88
[14791] 1538167075.243002: Sending TCP request to stream 172.21.162.211:88
[14791] 1538167075.244768: Received answer (1842 bytes) from stream 172.21.162.211:88
[14791] 1538167075.245459: Response was not from master KDC
[14791] 1538167075.245556: Decoding FAST response
[14791] 1538167075.245748: FAST reply key: rc4-hmac/F069
[14791] 1538167075.245871: TGS reply is for ***@TEST.COM -> ***@test.com with session key rc4-hmac/AEF0
[14791] 1538167075.245967: Got cred; 0/Success
[14791] 1538167075.246061: Resolving unique ccache of type MEMORY
[14791] 1538167075.246144: Initializing MEMORY:sAA7vI4 with default princ ***@TEST.COM
[14791] 1538167075.246270: Removing ***@test.com -> krbtgt/***@TEST.COM from MEMORY:sAA7vI4
[14791] 1538167075.246347: Storing ***@test.com -> krbtgt/***@TEST.COM in MEMORY:sAA7vI4
[14791] 1538167075.246444: Removing ***@test.com -> krb5_ccache_conf_data/pa_type/krbtgt\/TEST.COM\@***@X-CACHECONF: from MEMORY:sAA7vI4
[14791] 1538167075.246520: Storing ***@test.com -> krb5_ccache_conf_data/pa_type/krbtgt\/TEST.COM\@***@X-CACHECONF: in MEMORY:sAA7vI4
[14791] 1538167075.246613: Storing config in MEMORY:sAA7vI4 for : proxy_impersonator: ***@test.com
[14791] 1538167075.246737: Removing ***@TEST.COM -> krb5_ccache_conf_data/***@X-CACHECONF: from MEMORY:sAA7vI4
[14791] 1538167075.246813: Storing ***@TEST.COM -> krb5_ccache_conf_data/***@X-CACHECONF: in MEMORY:sAA7vI4
[14791] 1538167075.246891: Removing ***@TEST.COM -> ***@test.com from MEMORY:sAA7vI4
[14791] 1538167075.246963: Storing ***@TEST.COM -> ***@test.com in MEMORY:sAA7vI4
[14791] 1538167075.247319: Getting credentials ***@TEST.COM -> ***@test.com using ccache FILE:/tmp/krb5cc_0
[14791] 1538167075.247489: Retrieving ***@TEST.COM -> ***@test.com from FILE:/tmp/krb5cc_0 with result: -1765328243/Matching credential not found
[14791] 1538167075.247576: Getting credentials ***@test.com -> krbtgt/***@TEST.COM using ccache FILE:/tmp/krb5cc_0
[14791] 1538167075.247758: Retrieving ***@test.com -> krbtgt/***@TEST.COM from FILE:/tmp/krb5cc_0 with result: 0/Success
[14791] 1538167075.247863: Get cred via TGT krbtgt/***@TEST.COM after requesting ***@test.com (canonicalize on)
[14791] 1538167075.247953: Generated subkey for TGS request: rc4-hmac/F169
[14791] 1538167075.248043: etypes requested in TGS request: aes256-cts, aes128-cts, des3-cbc-sha1, rc4-hmac, camellia128-cts, camellia256-cts
[14791] 1538167075.248184: Encoding request body and padata into FAST request
[14791] 1538167075.248353: Sending request (2176 bytes) to TEST.COM
[14791] 1538167075.248448: Resolving hostname 172.21.162.211
[14791] 1538167075.248605: Initiating TCP connection to stream 172.21.162.211:88
[14791] 1538167075.248931: Sending TCP request to stream 172.21.162.211:88
[14791] 1538167075.250602: Received answer (1842 bytes) from stream 172.21.162.211:88
[14791] 1538167075.251358: Response was not from master KDC
[14791] 1538167075.251478: Decoding FAST response
[14791] 1538167075.251629: FAST reply key: rc4-hmac/E50D
[14791] 1538167075.251805: TGS reply is for ***@TEST.COM -> ***@test.com with session key rc4-hmac/F1B4
[14791] 1538167075.251901: Got cred; 0/Success
[14791] 1538167075.251999: Resolving unique ccache of type MEMORY
[14791] 1538167075.252080: Initializing MEMORY:2zEVGbO with default princ ***@TEST.COM
[14791] 1538167075.252202: Removing ***@test.com -> krbtgt/***@TEST.COM from MEMORY:2zEVGbO
[14791] 1538167075.252276: Storing ***@test.com -> krbtgt/***@TEST.COM in MEMORY:2zEVGbO
[14791] 1538167075.252371: Removing ***@test.com -> krb5_ccache_conf_data/pa_type/krbtgt\/TEST.COM\@***@X-CACHECONF: from MEMORY:2zEVGbO
[14791] 1538167075.252448: Storing ***@test.com -> krb5_ccache_conf_data/pa_type/krbtgt\/TEST.COM\@***@X-CACHECONF: in MEMORY:2zEVGbO
[14791] 1538167075.252538: Storing config in MEMORY:2zEVGbO for : proxy_impersonator: ***@test.com
[14791] 1538167075.252614: Removing ***@TEST.COM -> krb5_ccache_conf_data/***@X-CACHECONF: from MEMORY:2zEVGbO
[14791] 1538167075.252721: Storing ***@TEST.COM -> krb5_ccache_conf_data/***@X-CACHECONF: in MEMORY:2zEVGbO
[14791] 1538167075.252802: Removing ***@TEST.COM -> ***@test.com from MEMORY:2zEVGbO
[14791] 1538167075.252873: Storing ***@TEST.COM -> ***@test.com in MEMORY:2zEVGbO
[14791] 1538167075.253224: Getting credentials ***@TEST.COM -> ***@test.com using ccache FILE:/tmp/krb5cc_0
[14791] 1538167075.253394: Retrieving ***@TEST.COM -> ***@test.com from FILE:/tmp/krb5cc_0 with result: -1765328243/Matching credential not found
[14791] 1538167075.253482: Getting credentials ***@test.com -> krbtgt/***@TEST.COM using ccache FILE:/tmp/krb5cc_0
[14791] 1538167075.253634: Retrieving ***@test.com -> krbtgt/***@TEST.COM from FILE:/tmp/krb5cc_0 with result: 0/Success
[14791] 1538167075.253798: Get cred via TGT krbtgt/***@TEST.COM after requesting ***@test.com (canonicalize on)
[14791] 1538167075.253893: Generated subkey for TGS request: rc4-hmac/0FA7
[14791] 1538167075.253985: etypes requested in TGS request: aes256-cts, aes128-cts, des3-cbc-sha1, rc4-hmac, camellia128-cts, camellia256-cts
[14791] 1538167075.254128: Encoding request body and padata into FAST request
[14791] 1538167075.254285: Sending request (2176 bytes) to TEST.COM
[14791] 1538167075.254380: Resolving hostname 172.21.162.211
[14791] 1538167075.254531: Initiating TCP connection to stream 172.21.162.211:88
[14791] 1538167075.254767: Sending TCP request to stream 172.21.162.211:88
[14791] 1538167075.256452: Received answer (1842 bytes) from stream 172.21.162.211:88
[14791] 1538167075.257177: Response was not from master KDC
[14791] 1538167075.257272: Decoding FAST response
[14791] 1538167075.257422: FAST reply key: rc4-hmac/F998
[14791] 1538167075.257538: TGS reply is for ***@TEST.COM -> ***@test.com with session key rc4-hmac/6958
[14791] 1538167075.257633: Got cred; 0/Success
[14791] 1538167075.257759: Resolving unique ccache of type MEMORY
[14791] 1538167075.257845: Initializing MEMORY:mhj20wl with default princ ***@TEST.COM
[14791] 1538167075.257968: Removing ***@test.com -> krbtgt/***@TEST.COM from MEMORY:mhj20wl
[14791] 1538167075.258044: Storing ***@test.com -> krbtgt/***@TEST.COM in MEMORY:mhj20wl
[14791] 1538167075.258140: Removing ***@test.com -> krb5_ccache_conf_data/pa_type/krbtgt\/TEST.COM\@***@X-CACHECONF: from MEMORY:mhj20wl
[14791] 1538167075.258224: Storing ***@test.com -> krb5_ccache_conf_data/pa_type/krbtgt\/TEST.COM\@***@X-CACHECONF: in MEMORY:mhj20wl
[14791] 1538167075.258330: Storing config in MEMORY:mhj20wl for : proxy_impersonator: ***@test.com
[14791] 1538167075.258407: Removing ***@TEST.COM -> krb5_ccache_conf_data/***@X-CACHECONF: from MEMORY:mhj20wl
[14791] 1538167075.258478: Storing ***@TEST.COM -> krb5_ccache_conf_data/***@X-CACHECONF: in MEMORY:mhj20wl
[14791] 1538167075.258552: Removing ***@TEST.COM -> ***@test.com from MEMORY:mhj20wl
[14791] 1538167075.258623: Storing ***@TEST.COM -> ***@test.com in MEMORY:mhj20wl
[14791] 1538167075.258994: Getting credentials ***@TEST.COM -> ***@test.com using ccache FILE:/tmp/krb5cc_0
[14791] 1538167075.259163: Retrieving ***@TEST.COM -> ***@test.com from FILE:/tmp/krb5cc_0 with result: -1765328243/Matching credential not found
[14791] 1538167075.259251: Getting credentials ***@test.com -> krbtgt/***@TEST.COM using ccache FILE:/tmp/krb5cc_0
[14791] 1538167075.259403: Retrieving ***@test.com -> krbtgt/***@TEST.COM from FILE:/tmp/krb5cc_0 with result: 0/Success
[14791] 1538167075.259503: Get cred via TGT krbtgt/***@TEST.COM after requesting ***@test.com (canonicalize on)
[14791] 1538167075.259593: Generated subkey for TGS request: rc4-hmac/1E3B
[14791] 1538167075.259709: etypes requested in TGS request: aes256-cts, aes128-cts, des3-cbc-sha1, rc4-hmac, camellia128-cts, camellia256-cts
[14791] 1538167075.259860: Encoding request body and padata into FAST request
[14791] 1538167075.260017: Sending request (2176 bytes) to TEST.COM
[14791] 1538167075.260113: Resolving hostname 172.21.162.211
[14791] 1538167075.260264: Initiating TCP connection to stream 172.21.162.211:88
[14791] 1538167075.260492: Sending TCP request to stream 172.21.162.211:88
[14791] 1538167075.262157: Received answer (1842 bytes) from stream 172.21.162.211:88
[14791] 1538167075.263296: Response was not from master KDC
[14791] 1538167075.263396: Decoding FAST response
[14791] 1538167075.263545: FAST reply key: rc4-hmac/C06A
[14791] 1538167075.263659: TGS reply is for ***@TEST.COM -> ***@test.com with session key rc4-hmac/A45B
[14791] 1538167075.263783: Got cred; 0/Success
[14791] 1538167075.263873: Resolving unique ccache of type MEMORY
[14791] 1538167075.263951: Initializing MEMORY:KH07w0C with default princ ***@TEST.COM
[14791] 1538167075.264079: Removing ***@test.com -> krbtgt/***@TEST.COM from MEMORY:KH07w0C
[14791] 1538167075.264156: Storing ***@test.com -> krbtgt/***@TEST.COM in MEMORY:KH07w0C
[14791] 1538167075.264252: Removing ***@test.com -> krb5_ccache_conf_data/pa_type/krbtgt\/TEST.COM\@***@X-CACHECONF: from MEMORY:KH07w0C
[14791] 1538167075.264320: Storing ***@test.com -> krb5_ccache_conf_data/pa_type/krbtgt\/TEST.COM\@***@X-CACHECONF: in MEMORY:KH07w0C
[14791] 1538167075.264398: Storing config in MEMORY:KH07w0C for : proxy_impersonator: ***@test.com
[14791] 1538167075.264464: Removing ***@TEST.COM -> krb5_ccache_conf_data/***@X-CACHECONF: from MEMORY:KH07w0C
[14791] 1538167075.264523: Storing ***@TEST.COM -> krb5_ccache_conf_data/***@X-CACHECONF: in MEMORY:KH07w0C
[14791] 1538167075.264588: Removing ***@TEST.COM -> ***@test.com from MEMORY:KH07w0C
[14791] 1538167075.264648: Storing ***@TEST.COM -> ***@test.com in MEMORY:KH07w0C
[14791] 1538167075.265171: Getting credentials ***@TEST.COM -> ***@test.com using ccache MEMORY:sAA7vI4
[14791] 1538167075.265276: Retrieving ***@TEST.COM -> ***@test.com from MEMORY:sAA7vI4 with result: 0/Success
[14791] 1538167075.265424: Creating authenticator for ***@TEST.COM -> ***@test.com, seqnum 774377519, subkey rc4-hmac/46AC, session key rc4-hmac/AEF0
[14791] 1538167075.265952: Decrypted AP-REQ with server principal ***@test.com: rc4-hmac/2163
[14791] 1538167075.266046: AP-REQ ticket: ***@TEST.COM -> ***@test.com, session key rc4-hmac/AEF0
[14791] 1538167075.266387: Negotiated enctype based on authenticator: rc4-hmac
[14791] 1538167075.266462: Authenticator contains subkey: rc4-hmac/46AC
[14791] 1538167075.266554: Resolving unique ccache of type MEMORY
[14791] 1538167075.266631: Initializing MEMORY:narfKr4 with default princ ***@TEST.COM
[14791] 1538167075.266831: Removing ***@test.com -> krbtgt/***@TEST.COM from MEMORY:narfKr4
[14791] 1538167075.266921: Storing ***@test.com -> krbtgt/***@TEST.COM in MEMORY:narfKr4
[14791] 1538167075.267043: Removing ***@test.com -> krb5_ccache_conf_data/pa_type/krbtgt\/TEST.COM\@***@X-CACHECONF: from MEMORY:narfKr4
[14791] 1538167075.267137: Storing ***@test.com -> krb5_ccache_conf_data/pa_type/krbtgt\/TEST.COM\@***@X-CACHECONF: in MEMORY:narfKr4
[14791] 1538167075.267223: Storing config in MEMORY:narfKr4 for : proxy_impersonator: ***@test.com
[14791] 1538167075.267292: Removing ***@TEST.COM -> krb5_ccache_conf_data/***@X-CACHECONF: from MEMORY:narfKr4
[14791] 1538167075.267352: Storing ***@TEST.COM -> krb5_ccache_conf_data/***@X-CACHECONF: in MEMORY:narfKr4
[14791] 1538167075.267419: Removing ***@TEST.COM -> ***@test.com from MEMORY:narfKr4
[14791] 1538167075.267478: Storing ***@TEST.COM -> ***@test.com in MEMORY:narfKr4
[14791] 1538167075.268760: Retrieving ***@TEST.COM -> ***@test.com from MEMORY:narfKr4 with result: 0/Success
[14791] 1538167075.268838: Getting credentials ***@test.com -> http/***@TEST.COM using ccache MEMORY:narfKr4
[14791] 1538167075.268942: Retrieving ***@test.com -> krbtgt/***@TEST.COM from MEMORY:narfKr4 with result: 0/Success
[14791] 1538167075.269007: Starting with TGT for client realm: ***@test.com -> krbtgt/***@TEST.COM
[14791] 1538167075.269065: Requesting tickets for http/***@TEST.COM, referrals on
[14791] 1538167075.269139: Generated subkey for TGS request: rc4-hmac/68E3
[14791] 1538167075.269221: etypes requested in TGS request: aes256-cts, aes128-cts, des3-cbc-sha1, rc4-hmac, camellia128-cts, camellia256-cts
[14791] 1538167075.269369: Encoding request body and padata into FAST request
[14791] 1538167075.269577: Sending request (4026 bytes) to TEST.COM
[14791] 1538167075.269685: Resolving hostname 172.21.162.211
[14791] 1538167075.269846: Initiating TCP connection to stream 172.21.162.211:88
[14791] 1538167075.270110: Sending TCP request to stream 172.21.162.211:88
[14791] 1538167075.272750: Received answer (1932 bytes) from stream 172.21.162.211:88
[14791] 1538167075.273519: Response was not from master KDC
[14791] 1538167075.273623: Decoding FAST response
[14791] 1538167075.273844: FAST reply key: rc4-hmac/25D0
[14791] 1538167075.273980: TGS reply is for ***@TEST.COM -> http/***@TEST.COM with session key aes256-cts/81DC
[14791] 1538167075.274086: TGS request result: 0/Success
[14791] 1538167075.274161: Received creds for desired service http/***@TEST.COM
[14791] 1538167075.274236: Removing ***@TEST.COM -> http/***@TEST.COM from MEMORY:narfKr4
[14791] 1538167075.274310: Storing ***@TEST.COM -> http/***@TEST.COM in MEMORY:narfKr4
[14791] 1538167075.274464: Creating authenticator for ***@TEST.COM -> http/***@TEST.COM, seqnum 1049723237, subkey aes256-cts/323A, session key aes256-cts/81DC
[14791] 1538167075.275185: Destroying ccache MEMORY:narfKr4
[14791] 1538167075.275320: Destroying ccache MEMORY:sAA7vI4
[14791] 1538167075.275477: Destroying ccache MEMORY:2zEVGbO
[14791] 1538167075.275631: Destroying ccache MEMORY:mhj20wl
[14791] 1538167075.275851: Destroying ccache MEMORY:KH07w0C

Post by moore moore
This is really helpful and makes alot of sense. Thank you for the detailed info.
"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
expires."
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
Kerberized Server.

Post by moore moore
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.

Post by moore moore
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?

Post by moore moore
Is this the correct and only way for the proxy to "refresh" the service ticket?

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.

Post by moore moore
Thank you.

-derek

[moore moore]

Hello Derek,
After some further research, if I understand a bit better, the AP request between proxy and service is being delivered over SPNEGO.It is incorrect to think that it would have been explicitly visible in the trace between proxy and KDC, since it will be in the HTTP request from proxy to server.
Maybe the following is the reason I get so many 401 reauths from the server:
From 3.2.2.  Generation of a KRB_AP_REQ Message in RFC4120
"Authenticators MUST NOT be re-used and SHOULD be rejected if replayed to a server."

So if I understand based on your previous info also, would the following be on the correct path:
- cache the service ticket- on reauths, generate new authenticator and reuse a cached service ticket- somehow encapsulate the service ticket and NEW authenticator into AP REQ- deliver over SPNEGO to the server on kerberised server.- thus eliminating the need for excessive round trips from proxy to KDC
If this is practical, I will try figure out the kerb library API.
Appreciate your help.

On Tuesday 6 November 2018, 23:12:00 GMT, moore moore <***@yahoo.ie> wrote:

Hello Derek,Thanks again for the helpful information..
Time skew is not present and the service ticket is cached.

OK, so at the moment, everytime there is a 401 from the kerberised windows server, the application process (on the proxy), goes to the KDC.
In wireshark, this always shows as a TGS-REQ/TGS-RSP
I never see a AP-REQ/AP-RSP in the trace/wireshark.BUT, but looking the kerberos library logs, I see it mentioned there.And then I checked tcpdump and I see AP-REQ as a value in some of the TGS-REQs.

Sample kerb log below.

Here there is
- AS-REQ and pre auth requested for ***@test.com user.
- AS-REQ and RSP for ***@test.com user.
- Sample TGS-REQ/RSP for ***@test.com ( can see AP-REQ) in log.
This is between proxy and KDC.So not sure, if I can get some data/token from this? and use between proxy and service.Which is over HTTP SPNEGO.

Is the sample code/api documentation you could refer me to so I could try understand how to build and use the AP-REQ?
Thank you for your time.


[14791] 1538167075.224560: Getting initial credentials for ***@test.com
[14791] 1538167075.225189: Looked up etypes in keytab: rc4-hmac
[14791] 1538167075.225577: Sending request (177 bytes) to TEST.COM
[14791] 1538167075.225915: Resolving hostname 172.21.162.211
[14791] 1538167075.226408: Sending initial UDP request to dgram 172.21.162.211:88
[14791] 1538167075.227366: Received answer (214 bytes) from dgram 172.21.162.211:88
[14791] 1538167075.228299: Response was not from master KDC
[14791] 1538167075.228471: Received error from KDC: -1765328359/Additional pre-authentication required
[14791] 1538167075.228653: Processing preauth types: 16, 15, 19, 2
[14791] 1538167075.228829: Selected etype info: etype rc4-hmac, salt "", params ""
[14791] 1538167075.229021: Retrieving ***@test.com from FILE:/etc/krb5.keytab (vno 0, enctype rc4-hmac) with result: 0/Success
[14791] 1538167075.229146: AS key obtained for encrypted timestamp: rc4-hmac/2163
[14791] 1538167075.229309: Encrypted timestamp (for 1538167075.859690): plain 301AA011180F32303138303932383230333735355AA10502030D1E2A, encrypted 717BCF6554C1F514AB6D86FB08D00E9BEA7EF1B56C6996DA76E0AB5D9812D5E0C4233E6DC88A7EEA6582FA5FDC22ADB86F95D178
[14791] 1538167075.229428: Preauth module encrypted_timestamp (2) (real) returned: 0/Success
[14791] 1538167075.229520: Produced preauth for next request: 2
[14791] 1538167075.229625: Sending request (251 bytes) to TEST.COM
[14791] 1538167075.229750: Resolving hostname 172.21.162.211
[14791] 1538167075.229923: Sending initial UDP request to dgram 172.21.162.211:88
[14791] 1538167075.230849: Received answer (98 bytes) from dgram 172.21.162.211:88
[14791] 1538167075.231488: Response was not from master KDC
[14791] 1538167075.231613: Received error from KDC: -1765328332/Response too big for UDP, retry with TCP
[14791] 1538167075.231736: Request or response is too big for UDP; retrying with TCP
[14791] 1538167075.231832: Sending request (251 bytes) to TEST.COM (tcp only)
[14791] 1538167075.231927: Resolving hostname 172.21.162.211
[14791] 1538167075.232095: Initiating TCP connection to stream 172.21.162.211:88
[14791] 1538167075.232374: Sending TCP request to stream 172.21.162.211:88
[14791] 1538167075.233225: Received answer (1548 bytes) from stream 172.21.162.211:88
[14791] 1538167075.233701: Response was not from master KDC
[14791] 1538167075.233829: Salt derived from principal: TEST.COMproxy
[14791] 1538167075.233933: AS key determined by preauth: rc4-hmac/2163
[14791] 1538167075.234083: Decrypted AS reply; session key is: rc4-hmac/FAF6
[14791] 1538167075.234202: FAST negotiation: unavailable
[14791] 1538167075.234328: Initializing FILE:/tmp/krb5cc_0 with default princ ***@test.com
[14791] 1538167075.234524: Removing ***@test.com -> krbtgt/***@TEST.COM from FILE:/tmp/krb5cc_0
[14791] 1538167075.234629: Storing ***@test.com -> krbtgt/***@TEST.COM in FILE:/tmp/krb5cc_0
[14791] 1538167075.234885: Storing config in FILE:/tmp/krb5cc_0 for krbtgt/***@TEST.COM: pa_type: 2
[14791] 1538167075.235039: Removing ***@test.com -> krb5_ccache_conf_data/pa_type/krbtgt\/TEST.COM\@***@X-CACHECONF: from FILE:/tmp/krb5cc_0
[14791] 1538167075.235143: Storing ***@test.com -> krb5_ccache_conf_data/pa_type/krbtgt\/TEST.COM\@***@X-CACHECONF: in FILE:/tmp/krb5cc_0
[14791] 1538167075.241199: Getting credentials ***@TEST.COM -> ***@test.com using ccache FILE:/tmp/krb5cc_0
[14791] 1538167075.241446: Retrieving ***@TEST.COM -> ***@test.com from FILE:/tmp/krb5cc_0 with result: -1765328243/Matching credential not found
[14791] 1538167075.241571: Getting credentials ***@test.com -> krbtgt/***@TEST.COM using ccache FILE:/tmp/krb5cc_0
[14791] 1538167075.241755: Retrieving ***@test.com -> krbtgt/***@TEST.COM from FILE:/tmp/krb5cc_0 with result: 0/Success
[14791] 1538167075.241886: Get cred via TGT krbtgt/***@TEST.COM after requesting ***@test.com (canonicalize on)
[14791] 1538167075.241986: Generated subkey for TGS request: rc4-hmac/86EA
[14791] 1538167075.242096: etypes requested in TGS request: aes256-cts, aes128-cts, des3-cbc-sha1, rc4-hmac, camellia128-cts, camellia256-cts
[14791] 1538167075.242257: Encoding request body and padata into FAST request
[14791] 1538167075.242433: Sending request (2176 bytes) to TEST.COM
[14791] 1538167075.242534: Resolving hostname 172.21.162.211
[14791] 1538167075.242729: Initiating TCP connection to stream 172.21.162.211:88
[14791] 1538167075.243002: Sending TCP request to stream 172.21.162.211:88
[14791] 1538167075.244768: Received answer (1842 bytes) from stream 172.21.162.211:88
[14791] 1538167075.245459: Response was not from master KDC
[14791] 1538167075.245556: Decoding FAST response
[14791] 1538167075.245748: FAST reply key: rc4-hmac/F069
[14791] 1538167075.245871: TGS reply is for ***@TEST.COM -> ***@test.com with session key rc4-hmac/AEF0
[14791] 1538167075.245967: Got cred; 0/Success
[14791] 1538167075.246061: Resolving unique ccache of type MEMORY
[14791] 1538167075.246144: Initializing MEMORY:sAA7vI4 with default princ ***@TEST.COM
[14791] 1538167075.246270: Removing ***@test.com -> krbtgt/***@TEST.COM from MEMORY:sAA7vI4
[14791] 1538167075.246347: Storing ***@test.com -> krbtgt/***@TEST.COM in MEMORY:sAA7vI4
[14791] 1538167075.246444: Removing ***@test.com -> krb5_ccache_conf_data/pa_type/krbtgt\/TEST.COM\@***@X-CACHECONF: from MEMORY:sAA7vI4
[14791] 1538167075.246520: Storing ***@test.com -> krb5_ccache_conf_data/pa_type/krbtgt\/TEST.COM\@***@X-CACHECONF: in MEMORY:sAA7vI4
[14791] 1538167075.246613: Storing config in MEMORY:sAA7vI4 for : proxy_impersonator: ***@test.com
[14791] 1538167075.246737: Removing ***@TEST.COM -> krb5_ccache_conf_data/***@X-CACHECONF: from MEMORY:sAA7vI4
[14791] 1538167075.246813: Storing ***@TEST.COM -> krb5_ccache_conf_data/***@X-CACHECONF: in MEMORY:sAA7vI4
[14791] 1538167075.246891: Removing ***@TEST.COM -> ***@test.com from MEMORY:sAA7vI4
[14791] 1538167075.246963: Storing ***@TEST.COM -> ***@test.com in MEMORY:sAA7vI4
[14791] 1538167075.247319: Getting credentials ***@TEST.COM -> ***@test.com using ccache FILE:/tmp/krb5cc_0
[14791] 1538167075.247489: Retrieving ***@TEST.COM -> ***@test.com from FILE:/tmp/krb5cc_0 with result: -1765328243/Matching credential not found
[14791] 1538167075.247576: Getting credentials ***@test.com -> krbtgt/***@TEST.COM using ccache FILE:/tmp/krb5cc_0
[14791] 1538167075.247758: Retrieving ***@test.com -> krbtgt/***@TEST.COM from FILE:/tmp/krb5cc_0 with result: 0/Success
[14791] 1538167075.247863: Get cred via TGT krbtgt/***@TEST.COM after requesting ***@test.com (canonicalize on)
[14791] 1538167075.247953: Generated subkey for TGS request: rc4-hmac/F169
[14791] 1538167075.248043: etypes requested in TGS request: aes256-cts, aes128-cts, des3-cbc-sha1, rc4-hmac, camellia128-cts, camellia256-cts
[14791] 1538167075.248184: Encoding request body and padata into FAST request
[14791] 1538167075.248353: Sending request (2176 bytes) to TEST.COM
[14791] 1538167075.248448: Resolving hostname 172.21.162.211
[14791] 1538167075.248605: Initiating TCP connection to stream 172.21.162.211:88
[14791] 1538167075.248931: Sending TCP request to stream 172.21.162.211:88
[14791] 1538167075.250602: Received answer (1842 bytes) from stream 172.21.162.211:88
[14791] 1538167075.251358: Response was not from master KDC
[14791] 1538167075.251478: Decoding FAST response
[14791] 1538167075.251629: FAST reply key: rc4-hmac/E50D
[14791] 1538167075.251805: TGS reply is for ***@TEST.COM -> ***@test.com with session key rc4-hmac/F1B4
[14791] 1538167075.251901: Got cred; 0/Success
[14791] 1538167075.251999: Resolving unique ccache of type MEMORY
[14791] 1538167075.252080: Initializing MEMORY:2zEVGbO with default princ ***@TEST.COM
[14791] 1538167075.252202: Removing ***@test.com -> krbtgt/***@TEST.COM from MEMORY:2zEVGbO
[14791] 1538167075.252276: Storing ***@test.com -> krbtgt/***@TEST.COM in MEMORY:2zEVGbO
[14791] 1538167075.252371: Removing ***@test.com -> krb5_ccache_conf_data/pa_type/krbtgt\/TEST.COM\@***@X-CACHECONF: from MEMORY:2zEVGbO
[14791] 1538167075.252448: Storing ***@test.com -> krb5_ccache_conf_data/pa_type/krbtgt\/TEST.COM\@***@X-CACHECONF: in MEMORY:2zEVGbO
[14791] 1538167075.252538: Storing config in MEMORY:2zEVGbO for : proxy_impersonator: ***@test.com
[14791] 1538167075.252614: Removing ***@TEST.COM -> krb5_ccache_conf_data/***@X-CACHECONF: from MEMORY:2zEVGbO
[14791] 1538167075.252721: Storing ***@TEST.COM -> krb5_ccache_conf_data/***@X-CACHECONF: in MEMORY:2zEVGbO
[14791] 1538167075.252802: Removing ***@TEST.COM -> ***@test.com from MEMORY:2zEVGbO
[14791] 1538167075.252873: Storing ***@TEST.COM -> ***@test.com in MEMORY:2zEVGbO
[14791] 1538167075.253224: Getting credentials ***@TEST.COM -> ***@test.com using ccache FILE:/tmp/krb5cc_0
[14791] 1538167075.253394: Retrieving ***@TEST.COM -> ***@test.com from FILE:/tmp/krb5cc_0 with result: -1765328243/Matching credential not found
[14791] 1538167075.253482: Getting credentials ***@test.com -> krbtgt/***@TEST.COM using ccache FILE:/tmp/krb5cc_0
[14791] 1538167075.253634: Retrieving ***@test.com -> krbtgt/***@TEST.COM from FILE:/tmp/krb5cc_0 with result: 0/Success
[14791] 1538167075.253798: Get cred via TGT krbtgt/***@TEST.COM after requesting ***@test.com (canonicalize on)
[14791] 1538167075.253893: Generated subkey for TGS request: rc4-hmac/0FA7
[14791] 1538167075.253985: etypes requested in TGS request: aes256-cts, aes128-cts, des3-cbc-sha1, rc4-hmac, camellia128-cts, camellia256-cts
[14791] 1538167075.254128: Encoding request body and padata into FAST request
[14791] 1538167075.254285: Sending request (2176 bytes) to TEST.COM
[14791] 1538167075.254380: Resolving hostname 172.21.162.211
[14791] 1538167075.254531: Initiating TCP connection to stream 172.21.162.211:88
[14791] 1538167075.254767: Sending TCP request to stream 172.21.162.211:88
[14791] 1538167075.256452: Received answer (1842 bytes) from stream 172.21.162.211:88
[14791] 1538167075.257177: Response was not from master KDC
[14791] 1538167075.257272: Decoding FAST response
[14791] 1538167075.257422: FAST reply key: rc4-hmac/F998
[14791] 1538167075.257538: TGS reply is for ***@TEST.COM -> ***@test.com with session key rc4-hmac/6958
[14791] 1538167075.257633: Got cred; 0/Success
[14791] 1538167075.257759: Resolving unique ccache of type MEMORY
[14791] 1538167075.257845: Initializing MEMORY:mhj20wl with default princ ***@TEST.COM
[14791] 1538167075.257968: Removing ***@test.com -> krbtgt/***@TEST.COM from MEMORY:mhj20wl
[14791] 1538167075.258044: Storing ***@test.com -> krbtgt/***@TEST.COM in MEMORY:mhj20wl
[14791] 1538167075.258140: Removing ***@test.com -> krb5_ccache_conf_data/pa_type/krbtgt\/TEST.COM\@***@X-CACHECONF: from MEMORY:mhj20wl
[14791] 1538167075.258224: Storing ***@test.com -> krb5_ccache_conf_data/pa_type/krbtgt\/TEST.COM\@***@X-CACHECONF: in MEMORY:mhj20wl
[14791] 1538167075.258330: Storing config in MEMORY:mhj20wl for : proxy_impersonator: ***@test.com
[14791] 1538167075.258407: Removing ***@TEST.COM -> krb5_ccache_conf_data/***@X-CACHECONF: from MEMORY:mhj20wl
[14791] 1538167075.258478: Storing ***@TEST.COM -> krb5_ccache_conf_data/***@X-CACHECONF: in MEMORY:mhj20wl
[14791] 1538167075.258552: Removing ***@TEST.COM -> ***@test.com from MEMORY:mhj20wl
[14791] 1538167075.258623: Storing ***@TEST.COM -> ***@test.com in MEMORY:mhj20wl
[14791] 1538167075.258994: Getting credentials ***@TEST.COM -> ***@test.com using ccache FILE:/tmp/krb5cc_0
[14791] 1538167075.259163: Retrieving ***@TEST.COM -> ***@test.com from FILE:/tmp/krb5cc_0 with result: -1765328243/Matching credential not found
[14791] 1538167075.259251: Getting credentials ***@test.com -> krbtgt/***@TEST.COM using ccache FILE:/tmp/krb5cc_0
[14791] 1538167075.259403: Retrieving ***@test.com -> krbtgt/***@TEST.COM from FILE:/tmp/krb5cc_0 with result: 0/Success
[14791] 1538167075.259503: Get cred via TGT krbtgt/***@TEST.COM after requesting ***@test.com (canonicalize on)
[14791] 1538167075.259593: Generated subkey for TGS request: rc4-hmac/1E3B
[14791] 1538167075.259709: etypes requested in TGS request: aes256-cts, aes128-cts, des3-cbc-sha1, rc4-hmac, camellia128-cts, camellia256-cts
[14791] 1538167075.259860: Encoding request body and padata into FAST request
[14791] 1538167075.260017: Sending request (2176 bytes) to TEST.COM
[14791] 1538167075.260113: Resolving hostname 172.21.162.211
[14791] 1538167075.260264: Initiating TCP connection to stream 172.21.162.211:88
[14791] 1538167075.260492: Sending TCP request to stream 172.21.162.211:88
[14791] 1538167075.262157: Received answer (1842 bytes) from stream 172.21.162.211:88
[14791] 1538167075.263296: Response was not from master KDC
[14791] 1538167075.263396: Decoding FAST response
[14791] 1538167075.263545: FAST reply key: rc4-hmac/C06A
[14791] 1538167075.263659: TGS reply is for ***@TEST.COM -> ***@test.com with session key rc4-hmac/A45B
[14791] 1538167075.263783: Got cred; 0/Success
[14791] 1538167075.263873: Resolving unique ccache of type MEMORY
[14791] 1538167075.263951: Initializing MEMORY:KH07w0C with default princ ***@TEST.COM
[14791] 1538167075.264079: Removing ***@test.com -> krbtgt/***@TEST.COM from MEMORY:KH07w0C
[14791] 1538167075.264156: Storing ***@test.com -> krbtgt/***@TEST.COM in MEMORY:KH07w0C
[14791] 1538167075.264252: Removing ***@test.com -> krb5_ccache_conf_data/pa_type/krbtgt\/TEST.COM\@***@X-CACHECONF: from MEMORY:KH07w0C
[14791] 1538167075.264320: Storing ***@test.com -> krb5_ccache_conf_data/pa_type/krbtgt\/TEST.COM\@***@X-CACHECONF: in MEMORY:KH07w0C
[14791] 1538167075.264398: Storing config in MEMORY:KH07w0C for : proxy_impersonator: ***@test.com
[14791] 1538167075.264464: Removing ***@TEST.COM -> krb5_ccache_conf_data/***@X-CACHECONF: from MEMORY:KH07w0C
[14791] 1538167075.264523: Storing ***@TEST.COM -> krb5_ccache_conf_data/***@X-CACHECONF: in MEMORY:KH07w0C
[14791] 1538167075.264588: Removing ***@TEST.COM -> ***@test.com from MEMORY:KH07w0C
[14791] 1538167075.264648: Storing ***@TEST.COM -> ***@test.com in MEMORY:KH07w0C
[14791] 1538167075.265171: Getting credentials ***@TEST.COM -> ***@test.com using ccache MEMORY:sAA7vI4
[14791] 1538167075.265276: Retrieving ***@TEST.COM -> ***@test.com from MEMORY:sAA7vI4 with result: 0/Success
[14791] 1538167075.265424: Creating authenticator for ***@TEST.COM -> ***@test.com, seqnum 774377519, subkey rc4-hmac/46AC, session key rc4-hmac/AEF0
[14791] 1538167075.265952: Decrypted AP-REQ with server principal ***@test.com: rc4-hmac/2163
[14791] 1538167075.266046: AP-REQ ticket: ***@TEST.COM -> ***@test.com, session key rc4-hmac/AEF0
[14791] 1538167075.266387: Negotiated enctype based on authenticator: rc4-hmac
[14791] 1538167075.266462: Authenticator contains subkey: rc4-hmac/46AC
[14791] 1538167075.266554: Resolving unique ccache of type MEMORY
[14791] 1538167075.266631: Initializing MEMORY:narfKr4 with default princ ***@TEST.COM
[14791] 1538167075.266831: Removing ***@test.com -> krbtgt/***@TEST.COM from MEMORY:narfKr4
[14791] 1538167075.266921: Storing ***@test.com -> krbtgt/***@TEST.COM in MEMORY:narfKr4
[14791] 1538167075.267043: Removing ***@test.com -> krb5_ccache_conf_data/pa_type/krbtgt\/TEST.COM\@***@X-CACHECONF: from MEMORY:narfKr4
[14791] 1538167075.267137: Storing ***@test.com -> krb5_ccache_conf_data/pa_type/krbtgt\/TEST.COM\@***@X-CACHECONF: in MEMORY:narfKr4
[14791] 1538167075.267223: Storing config in MEMORY:narfKr4 for : proxy_impersonator: ***@test.com
[14791] 1538167075.267292: Removing ***@TEST.COM -> krb5_ccache_conf_data/***@X-CACHECONF: from MEMORY:narfKr4
[14791] 1538167075.267352: Storing ***@TEST.COM -> krb5_ccache_conf_data/***@X-CACHECONF: in MEMORY:narfKr4
[14791] 1538167075.267419: Removing ***@TEST.COM -> ***@test.com from MEMORY:narfKr4
[14791] 1538167075.267478: Storing ***@TEST.COM -> ***@test.com in MEMORY:narfKr4
[14791] 1538167075.268760: Retrieving ***@TEST.COM -> ***@test.com from MEMORY:narfKr4 with result: 0/Success
[14791] 1538167075.268838: Getting credentials ***@test.com -> http/***@TEST.COM using ccache MEMORY:narfKr4
[14791] 1538167075.268942: Retrieving ***@test.com -> krbtgt/***@TEST.COM from MEMORY:narfKr4 with result: 0/Success
[14791] 1538167075.269007: Starting with TGT for client realm: ***@test.com -> krbtgt/***@TEST.COM
[14791] 1538167075.269065: Requesting tickets for http/***@TEST.COM, referrals on
[14791] 1538167075.269139: Generated subkey for TGS request: rc4-hmac/68E3
[14791] 1538167075.269221: etypes requested in TGS request: aes256-cts, aes128-cts, des3-cbc-sha1, rc4-hmac, camellia128-cts, camellia256-cts
[14791] 1538167075.269369: Encoding request body and padata into FAST request
[14791] 1538167075.269577: Sending request (4026 bytes) to TEST.COM
[14791] 1538167075.269685: Resolving hostname 172.21.162.211
[14791] 1538167075.269846: Initiating TCP connection to stream 172.21.162.211:88
[14791] 1538167075.270110: Sending TCP request to stream 172.21.162.211:88
[14791] 1538167075.272750: Received answer (1932 bytes) from stream 172.21.162.211:88
[14791] 1538167075.273519: Response was not from master KDC
[14791] 1538167075.273623: Decoding FAST response
[14791] 1538167075.273844: FAST reply key: rc4-hmac/25D0
[14791] 1538167075.273980: TGS reply is for ***@TEST.COM -> http/***@TEST.COM with session key aes256-cts/81DC
[14791] 1538167075.274086: TGS request result: 0/Success
[14791] 1538167075.274161: Received creds for desired service http/***@TEST.COM
[14791] 1538167075.274236: Removing ***@TEST.COM -> http/***@TEST.COM from MEMORY:narfKr4
[14791] 1538167075.274310: Storing ***@TEST.COM -> http/***@TEST.COM in MEMORY:narfKr4
[14791] 1538167075.274464: Creating authenticator for ***@TEST.COM -> http/***@TEST.COM, seqnum 1049723237, subkey aes256-cts/323A, session key aes256-cts/81DC
[14791] 1538167075.275185: Destroying ccache MEMORY:narfKr4
[14791] 1538167075.275320: Destroying ccache MEMORY:sAA7vI4
[14791] 1538167075.275477: Destroying ccache MEMORY:2zEVGbO
[14791] 1538167075.275631: Destroying ccache MEMORY:mhj20wl
[14791] 1538167075.275851: Destroying ccache MEMORY:KH07w0C

Post by moore moore
This is really helpful and makes alot of sense. Thank you for the detailed info.
"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
expires."
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
Kerberized Server.

Post by moore moore
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.

Post by moore moore
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?

Post by moore moore
Is this the correct and only way for the proxy to "refresh" the service ticket?

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.

Post by moore moore
Thank you.

-derek

[Derek Atkins]

Hi,

Post by moore moore
Hello Derek,
After some further research, if I understand a bit better, the AP request
between proxy and service is being delivered over SPNEGO.
It is incorrect to think that it would have been explicitly visible in the
trace between proxy and KDC, since it will be in the HTTP request from proxy
to server.

Correct.

Post by moore moore
From 3.2.2. Generation of a KRB_AP_REQ Message in RFC4120
"Authenticators MUST NOT be re-used and SHOULD be rejected if replayed to a server."
So if I understand based on your previous info also, would the following be on
- cache the service ticket
- on reauths, generate new authenticator and reuse a cached service ticket
- somehow encapsulate the service ticket and NEW authenticator into AP REQ

The "generate new authenticator" *is* creating a new AP REQ -- so there
is no "somehow" here, doing the former is doing the latter, and
vice-versa. If you create a new (as opposed to reusing a cached) AP REQ
then you are, by definition, creating a new authenticator. It sounds
like the AP-REQ auth-data is being cached and reused.

Post by moore moore
- deliver over SPNEGO to the server on kerberised server.
- thus eliminating the need for excessive round trips from proxy to KDC
If this is practical, I will try figure out the kerb library API.

Yes, this is exactly what I've been trying to explain that you need to do.

Post by moore moore
Appreciate your help.

You're welcome.

Post by moore moore
On Tuesday 6 November 2018, 23:12:00 GMT, moore moore
Hello Derek,
Thanks again for the helpful information..
Time skew is not present and the service ticket is cached.
OK, so at the moment, everytime there is a 401 from the kerberised windows
server, the application process (on the proxy), goes to the KDC.
In wireshark, this always shows as a TGS-REQ/TGS-RSP
I never see a AP-REQ/AP-RSP in the trace/wireshark.
BUT, but looking the kerberos library logs, I see it mentioned there.
And then I checked tcpdump and I see AP-REQ as a value in some of the
TGS-REQs.
Sample kerb log below.
Here there is
This is between proxy and KDC.
So not sure, if I can get some data/token from this? and use between proxy and
service.
Which is over HTTP SPNEGO.
Is the sample code/api documentation you could refer me to so I could try
understand how to build and use the AP-REQ?
Thank you for your time.
[14791] 1538167075.225189: Looked up etypes in keytab: rc4-hmac
[14791] 1538167075.225577: Sending request (177 bytes) to TEST.COM
[14791] 1538167075.225915: Resolving hostname 172.21.162.211
[14791] 1538167075.226408: Sending initial UDP request to dgram 172.21.162.211:88
[14791] 1538167075.227366: Received answer (214 bytes) from dgram 172.21.162.211:88
[14791] 1538167075.228299: Response was not from master KDC
[14791] 1538167075.228471: Received error from KDC: -1765328359/Additional
pre-authentication required
[14791] 1538167075.228653: Processing preauth types: 16, 15, 19, 2
[14791] 1538167075.228829: Selected etype info: etype rc4-hmac, salt "", params ""
FILE:/etc/krb5.keytab (vno 0, enctype rc4-hmac) with result: 0/Success
[14791] 1538167075.229146: AS key obtained for encrypted timestamp: rc4-hmac/
2163
[14791] 1538167075.229309: Encrypted timestamp (for 1538167075.859690): plain
301AA011180F32303138303932383230333735355AA10502030D1E2A, encrypted
717BCF6554C1F514AB6D86FB08D00E9BEA7EF1B56C6996DA76E0AB5D9812D5E0C4233E6DC88A7EEA6582FA5FDC22ADB86F95D178
[14791] 1538167075.229428: Preauth module encrypted_timestamp (2) (real)
returned: 0/Success
[14791] 1538167075.229520: Produced preauth for next request: 2
[14791] 1538167075.229625: Sending request (251 bytes) to TEST.COM
[14791] 1538167075.229750: Resolving hostname 172.21.162.211
[14791] 1538167075.229923: Sending initial UDP request to dgram 172.21.162.211:88
[14791] 1538167075.230849: Received answer (98 bytes) from dgram 172.21.162.211:88
[14791] 1538167075.231488: Response was not from master KDC
[14791] 1538167075.231613: Received error from KDC: -1765328332/Response too
big for UDP, retry with TCP
[14791] 1538167075.231736: Request or response is too big for UDP; retrying with TCP
[14791] 1538167075.231832: Sending request (251 bytes) to TEST.COM (tcp only)
[14791] 1538167075.231927: Resolving hostname 172.21.162.211
[14791] 1538167075.232095: Initiating TCP connection to stream
172.21.162.211:88
[14791] 1538167075.232374: Sending TCP request to stream 172.21.162.211:88
[14791] 1538167075.233225: Received answer (1548 bytes) from stream 172.21.162.211:88
[14791] 1538167075.233701: Response was not from master KDC
[14791] 1538167075.233829: Salt derived from principal: TEST.COMproxy
[14791] 1538167075.233933: AS key determined by preauth: rc4-hmac/2163
[14791] 1538167075.234083: Decrypted AS reply; session key is: rc4-hmac/FAF6
[14791] 1538167075.234202: FAST negotiation: unavailable
[14791] 1538167075.234328: Initializing FILE:/tmp/krb5cc_0 with default princ
from FILE:/tmp/krb5cc_0
in FILE:/tmp/krb5cc_0
[14791] 1538167075.234885: Storing config in FILE:/tmp/krb5cc_0 for krbtgt/
FILE:/tmp/krb5cc_0 with result: -1765328243/Matching credential not found
[14791] 1538167075.241986: Generated subkey for TGS request: rc4-hmac/86EA
[14791] 1538167075.242096: etypes requested in TGS request: aes256-cts,
aes128-cts, des3-cbc-sha1, rc4-hmac, camellia128-cts, camellia256-cts
[14791] 1538167075.242257: Encoding request body and padata into FAST request
[14791] 1538167075.242433: Sending request (2176 bytes) to TEST.COM
[14791] 1538167075.242534: Resolving hostname 172.21.162.211
[14791] 1538167075.242729: Initiating TCP connection to stream
172.21.162.211:88
[14791] 1538167075.243002: Sending TCP request to stream 172.21.162.211:88
[14791] 1538167075.244768: Received answer (1842 bytes) from stream 172.21.162.211:88
[14791] 1538167075.245459: Response was not from master KDC
[14791] 1538167075.245556: Decoding FAST response
[14791] 1538167075.245748: FAST reply key: rc4-hmac/F069
[14791] 1538167075.245967: Got cred; 0/Success
[14791] 1538167075.246061: Resolving unique ccache of type MEMORY
from MEMORY:sAA7vI4
in MEMORY:sAA7vI4
FILE:/tmp/krb5cc_0 with result: -1765328243/Matching credential not found
[14791] 1538167075.247953: Generated subkey for TGS request: rc4-hmac/F169
[14791] 1538167075.248043: etypes requested in TGS request: aes256-cts,
aes128-cts, des3-cbc-sha1, rc4-hmac, camellia128-cts, camellia256-cts
[14791] 1538167075.248184: Encoding request body and padata into FAST request
[14791] 1538167075.248353: Sending request (2176 bytes) to TEST.COM
[14791] 1538167075.248448: Resolving hostname 172.21.162.211
[14791] 1538167075.248605: Initiating TCP connection to stream
172.21.162.211:88
[14791] 1538167075.248931: Sending TCP request to stream 172.21.162.211:88
[14791] 1538167075.250602: Received answer (1842 bytes) from stream 172.21.162.211:88
[14791] 1538167075.251358: Response was not from master KDC
[14791] 1538167075.251478: Decoding FAST response
[14791] 1538167075.251629: FAST reply key: rc4-hmac/E50D
[14791] 1538167075.251901: Got cred; 0/Success
[14791] 1538167075.251999: Resolving unique ccache of type MEMORY
from MEMORY:2zEVGbO
in MEMORY:2zEVGbO
FILE:/tmp/krb5cc_0 with result: -1765328243/Matching credential not found
[14791] 1538167075.253893: Generated subkey for TGS request: rc4-hmac/0FA7
[14791] 1538167075.253985: etypes requested in TGS request: aes256-cts,
aes128-cts, des3-cbc-sha1, rc4-hmac, camellia128-cts, camellia256-cts
[14791] 1538167075.254128: Encoding request body and padata into FAST request
[14791] 1538167075.254285: Sending request (2176 bytes) to TEST.COM
[14791] 1538167075.254380: Resolving hostname 172.21.162.211
[14791] 1538167075.254531: Initiating TCP connection to stream
172.21.162.211:88
[14791] 1538167075.254767: Sending TCP request to stream 172.21.162.211:88
[14791] 1538167075.256452: Received answer (1842 bytes) from stream 172.21.162.211:88
[14791] 1538167075.257177: Response was not from master KDC
[14791] 1538167075.257272: Decoding FAST response
[14791] 1538167075.257422: FAST reply key: rc4-hmac/F998
[14791] 1538167075.257633: Got cred; 0/Success
[14791] 1538167075.257759: Resolving unique ccache of type MEMORY
from MEMORY:mhj20wl
in MEMORY:mhj20wl
FILE:/tmp/krb5cc_0 with result: -1765328243/Matching credential not found
[14791] 1538167075.259593: Generated subkey for TGS request: rc4-hmac/1E3B
[14791] 1538167075.259709: etypes requested in TGS request: aes256-cts,
aes128-cts, des3-cbc-sha1, rc4-hmac, camellia128-cts, camellia256-cts
[14791] 1538167075.259860: Encoding request body and padata into FAST request
[14791] 1538167075.260017: Sending request (2176 bytes) to TEST.COM
[14791] 1538167075.260113: Resolving hostname 172.21.162.211
[14791] 1538167075.260264: Initiating TCP connection to stream
172.21.162.211:88
[14791] 1538167075.260492: Sending TCP request to stream 172.21.162.211:88
[14791] 1538167075.262157: Received answer (1842 bytes) from stream 172.21.162.211:88
[14791] 1538167075.263296: Response was not from master KDC
[14791] 1538167075.263396: Decoding FAST response
[14791] 1538167075.263545: FAST reply key: rc4-hmac/C06A
[14791] 1538167075.263783: Got cred; 0/Success
[14791] 1538167075.263873: Resolving unique ccache of type MEMORY
from MEMORY:KH07w0C
in MEMORY:KH07w0C
MEMORY:sAA7vI4 with result: 0/Success
AEF0
[14791] 1538167075.265952: Decrypted AP-REQ with server principal
session key rc4-hmac/AEF0
[14791] 1538167075.266387: Negotiated enctype based on authenticator: rc4-hmac
[14791] 1538167075.266462: Authenticator contains subkey: rc4-hmac/46AC
[14791] 1538167075.266554: Resolving unique ccache of type MEMORY
from MEMORY:narfKr4
in MEMORY:narfKr4
MEMORY:narfKr4 with result: 0/Success
[14791] 1538167075.269065: Requesting tickets for http/
[14791] 1538167075.269139: Generated subkey for TGS request: rc4-hmac/68E3
[14791] 1538167075.269221: etypes requested in TGS request: aes256-cts,
aes128-cts, des3-cbc-sha1, rc4-hmac, camellia128-cts, camellia256-cts
[14791] 1538167075.269369: Encoding request body and padata into FAST request
[14791] 1538167075.269577: Sending request (4026 bytes) to TEST.COM
[14791] 1538167075.269685: Resolving hostname 172.21.162.211
[14791] 1538167075.269846: Initiating TCP connection to stream
172.21.162.211:88
[14791] 1538167075.270110: Sending TCP request to stream 172.21.162.211:88
[14791] 1538167075.272750: Received answer (1932 bytes) from stream 172.21.162.211:88
[14791] 1538167075.273519: Response was not from master KDC
[14791] 1538167075.273623: Decoding FAST response
[14791] 1538167075.273844: FAST reply key: rc4-hmac/25D0
[14791] 1538167075.274086: TGS request result: 0/Success
[14791] 1538167075.274161: Received creds for desired service http/
session key aes256-cts/81DC
[14791] 1538167075.275185: Destroying ccache MEMORY:narfKr4
[14791] 1538167075.275320: Destroying ccache MEMORY:sAA7vI4
[14791] 1538167075.275477: Destroying ccache MEMORY:2zEVGbO
[14791] 1538167075.275631: Destroying ccache MEMORY:mhj20wl
[14791] 1538167075.275851: Destroying ccache MEMORY:KH07w0C

Post by moore moore
This is really helpful and makes alot of sense. Thank you for the detailed info.
"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
expires."
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
Kerberized Server.

Post by moore moore
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.

Post by moore moore
But I get very little use out of the cached service ticket, due to the

demand

Post by moore moore
and frequency of the 401s.
When the 401 happens, ( in relation to your point 4), a series of TGS_REQ/

RSP

Post by moore moore
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,

Post by moore moore
but then will quickly issue 401s again, thus resulting in having to go back

to

Post by moore moore
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?

Post by moore moore
Is this the correct and only way for the proxy to "refresh" the service ticket?

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.

Post by moore moore
Thank you.

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