Internet Explorer <-> Puakma ESSO <-> MS Internet Information Server version 6
The ESSO version is very recent.
What we want is for an ASPX page located on the IIS to be able to retrieve the Domino LTPAtoken and then access Domino data using that token.
This works - we are seeing it working.
So, what is the problem?
Bascially when we do POST to the IIS through the ESSO, some of the NTLM handshaking is forwarded to the IIS. The IIS tries to do the handshaking, but somewhere in the communication ESSO, IIS and the IE client get confused.
When we do a GET we don't see this issue because IE does not try to do the NTLM handshake again.
By the way - we are using Wireshark to do packet sniffing on the server running Puakma ESSO in order to see what is going on.
I will try with a bit more detail for you:
We have a page on the IIS server. An aspx page. Bascially what it does is it looks for the LTPAtoken in the HTTP request from the browser user, it then includes that token when requesting data on a Domino server, thereby impersonating the Internet Explorer user. The page then build a return page that is displayed to the user.
The first time we access this aspx-page we do a GET. http:/server/pages/page.aspx.
No problems this far.
The page that is returned includes a button, and in the HTML we have a FORM tag. The button does a submit of the page - a POST. We are still located at the same URL - http:/server/pages/page.aspx.
And it is when we do the submit that we see the problem. It's odd.
The HTTP header of the POST request from Internet Explorer contains the LTPAtoken of course. But for some reason it also contains a "field" (by field i mean a HTTP header part just like the session cookie "field") with NTLM handshaking data.
The NTLM handshaking data that is included is exactly the same data that we have seen as part of the _initial_ NTLM hanshake. It's like the browser "thinks" "I'm doing a POST and I can see that earlier on I did a NTLM handshake, so just to make sure, I will re-initiate a hanshake".
So, what happens when ESSO gets this HTTP request. First it participates in the handshaking with IE. It starts requesting IE for more NTLM handshaking data and gets some, but then it looks like ESSO discovers that the request already contains a LTPAtoken, and it therfore decides to forward the POST to the IIS - _including_ the NTLM handshake data. And that's what makes things come apart - that the ESSO forwards the NTLM handshaking data. I don't have the details here, but it ends up with the IE timing out.
For debugging purposes we have also tried to include a simple link on the aspx page in question. One that leads from the first page to a second page on the IIS (GET). If we click such a link, we don't see the behaviour I describe above. Not NTLM handshake data is included ind the HTTP request, and everything works fine.
To me the obvious request would be for a way of configuring ESSO to not forward/proxy NTLM handshakes or to configure that specific HTTP header "fields" should not be forwareded/proxied.