IAG KCD breaking due to missing “keep-alive” header. Why ?

A few days ago, I was working with Fadhel Ben Brahem, one of our IAG experts working for Dictao, a Microsoft Partner. IAG was implemented in a very complex LAN/Switches/LoadBalancer environnent.

The goal, the failure

The goal of our Proof Of Concept was to implement IAG and demonstrate SSO capabilities, especially Kerberos Constrained Delegation (KCD). This scenario is very common, and usually we install it in a short period of time.

Unfortunately we were facing connection problems and decided to activate IAG “internal” tracing, just to guess what was going on.

The methodology : tracing

The component in IAG – for Web Applications – that does all this job is called WHLFilter. Once turned in “deep tracing mode”, it generated a lot of useful information in order to see what is happening during the reverse proxy phase. Problems could be due to IAG’s configuration, but also generated by the global IT environment. The log will help us to find a clue.

WhlFilter will show us all the requests arriving, then what this filter will do, then the request that will leave IAG towards the web application.. then exactly the same on the way back.

In our scenario, because we want to provide SSO using KCD, it will also show us what it is doing to get the Kerberos ticket on behalf of the user, etc.

Log analysis

We quickly found in the trace something breaking. According to the filter a missing “connection: Keep alive” was missing, causing the filter to stop his job:

  “32/13/2099 16:29:45.282 (tid: 00000CA8): CExtECB::Handle401StatusResponse - The browser does not use HTTP keep-alive. Filter is dropping down to basic scheme support *only*. (ExtECB=05AD5C58), (PFC=01180DA0)”

Back to the RFCs

If you look at the HTTP 1.1 RFC, keep-alive is described in details(https://www.w3.org/Protocols/HTTP/1.1/draft-ietf-http-v11-spec-01.html#Connection). Extract from the RFC : “10.9.1 Persistent Connections : The "keep-alive" keyword in a Connection header field allows the sender to indicate its desire for a persistent connection (i.e., a connection that lasts beyond the current request/response transaction). Persistent connections allow the client to perform multiple requests without the overhead of connection tear-down and set-up between each request. “

At this level, we understand what is keep-alive, but don’t really know why the filter is stopping his job.

In that RFC, we also have this comment “ Connection header fields received in an HTTP/1.0 message, as would be the case if an older proxy mistakenly forwards the field…” which in fact lead us to the solution : HTTP/1.0.

If you look at this example, the HTTP GET explicitly says that it is using HTTP 1.1. In HTTP 1.1, this “connection =xxx” is expected by an application (web application, IAG , ..) supporting also that version of the HTTP protocol :

The problem, the solution

In our scenario, the request received by IAG was saying “I am HTTP 1.1” but without any indication about the “connection” status. So for IAG, this is not “RFC” compliant, and IAG assume that the session has been closed, and stop the conversation. This petty much what the WhlFilter log is saying, with the words of the programmer of that feature ;-)

Just for test, I turned my IE to use only HTTP1.0…

… and did the same capture. As you can see, the browser is now using HTTP 1.0 :

The conclusion here is that “something” between the client (with an HTTPWatch/fiddler trace we can see that when the request leaves the client, both HTTP 1.1 and “connection: keep-alive” are here) and the server (thanks to WhlFilter trace) is corrupting this dialog.

In our scenario security equipment between the two was generating this behavior, and once we changed the configuration, it worked correctly. More interesting, we detected this problem when we looked at KCD, but it was a wrong assumption. KCD was not involved at all in that, all HTTP requests are inspected by IAG, so potentially could be dropped due to that non compliant request.

This example is very nice to use IAG tracing capabilities, in order to highlight problems coming from the “outside”

of IAG.

 

Thanks Fadhel for this efficient collaboration !

Comments

• Anonymous
  August 28, 2009
  I've encountered this problem thanks to information I've fixed the problem thanks ...