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 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.
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)”
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.
of IAG.
Thanks Fadhel for this efficient collaboration !
I've encountered this problem thanks to information I've fixed the problem thanks ...