iis security: Hi,

I am using IIS (5) as a gateway to a servlet container (I have a CGI &
ISAPI version of a gateway for this communication).

I am trying to implement NTLM authentication in the serlvet container
but when my servlet returns a 401 header I always get a 'Connection:
close' header added to the response by IIS. Even if I add my own
Connection header to the response, I end up with 2 headers, so my
Connection: keep-alive is ignored by the browser. In this case the
browser will end the connection and resend the type 1 NTLM request
again....

I have verified (using ethereal) that the response headers are modified
somewhere within IIS/ISAPI, but I dont know where - the only debug I
have from the ISAPI plugin seems to suggest that the response is not
modified there....

I do not have any issues with a 200 response code (i.e. I do not get a
Connection: close header)

Is this likely to be IIS or is it more likely the way that the ISAPI
plugin is writing to the client (browser). I understand from many
posts that the CGI version of my gateway will not work as IIS will
always force a Connection: close for CGIs....

thanks for your input

Hi jimbob,

You should never set a connection header in your response from CGI or ISAPI.
IIS will set the connection header itself based on the client HTTP version,
whether the client wants keep-alive or not, and whether the response from
IIS can support keep-alive.

It's clear from your description below that the keep-alive is not happening
in your response, and adding your own connection header will not change
this.

To resolve the issue, you need to know why IIS is closing the connection.
Without knowing exactly what you are doing and how you are doing it, there
are more possible causes of this than I could list here. Off the top of my
head, here are the big ones (assuming that the client supports keep-alive):

1. You are sending a response from CGI. IIS 5.1 and earlier do not support
keep-alive responses from CGI. (Off the top of my head, I don't remember if
this is true or not for IIS 6. We made a number of improvements to CGI, but
I'd have to look at the code to remember if this was one of them.)

2. You are sending a response from a filter. No version of IIS can support
sending a response from a filter without closing the connection.

3. You are sending a response from an extension with
HSE_REQ_SEND_RESPONSE_HEADER and you have not included a content-length
header in the response.

These are the most common ways that responses are sent back. If you are
sending the response differently, then I'd have to know exactly what calls
you are making to tell you whether the connection will need to close or not.

The other thing I am curious about is why you need to write your own NTLM
implementation instead of using the one built into IIS.

Thank you,
-Wade A. Hilmo,
-Microsoft

PS: The microsoft.public.platformsdk.internet.server.isapi-dev is a better
place for this discussion.

[quoted text, click to view]

Wade,

thanks for your excellent response!

First, my issue is only with MSIE (I am using v6). Firefox (can I
mention this on an MS group?) ignores the connection: close header in
the response and sends the type 3 message anyway. This may be a fault
or feature in firefox, but I know which way I see it!

Unfortunately your top 3 answers can be discounted:

1. I have a CGI and an ISAPI version of my gateway. I mentioned that
AFAIK CGI would not support keep-alive, so my described issue was
related to my ISAPI module. (moreover I am seeing the same behaviour
with IIS 6!)

2. A '200' reponse from my servlet container does not end up with a
Connection close header.

3. I see a content-length header in the response (ethereal and
ieHTTPHeaders)

I dont currently have access to the ISAPI code. It would be great if
there was a debug flag in IIS to help diagnose response transition
before/during/after 3rd party code.

The purpose of all this is to be able to determine (in the servlet
container) who is logged in to the remote windows box. I realise this
is apparently easy in a pure windows/asp world, but in my case I need
this info to be available outside this realm. In my scenario my ISAPI
plugin is configured for anonymous-auth only - in this way I can get
the HTTP_AUTHORIZATION header in my app server by following the NTLM
challenge/response mechanism. If there was another way to effectivley
pass remote windows username to a CGI/ISAPI module it would make life
MUCH easier. (Note - I have been googling a lot and just found that
maybe if I set integrated windows auth in IIS it will populate the
environment variable AUTH_USER - will try this)

Thanks again for your reply - and I will have a look at
microsoft.public.platformsdk.internet.server.isapi-dev to see if there
is anything else about this!

rgds
jim

Your issue is with your code (either ISAPI or CGI) and not with IIS6 and
MSIE.

I would never rely on a bug in a browser implementation as the means to get
my solution to work. Basically, two wrongs don't make a right:
1. Your ISAPI/CGI causes a response with multiple conflicting Connection:
headers. That is your bug
2. Firefox ignoring Connection: headers is also a bug

If either of you fixes your bug, your "solution" breaks. That doesn't sound
like a real solution to me. :-)


[quoted text, click to view]

IIS6 in Windows Server 2003 SP1 has ETW Tracing which does exactly this. Not
available on any other IIS version.


I presume your ISAPI/CGI is the only thing that is forwarding requests from
the IIS gatewary to your Servlet Engine (and you have code in the Servlet
Container that subsequently unwraps any forwarded metadata and performs
man-in-the-middle attack as appropriate to hack in the user name).

Thus, if all you want is the authenticated username from IIS in the Servlet
Container, you should:
1. Let IIS finish authenticating the remote user using whatever protocol you
defined in IIS
2. After authentication is complete, AUTH_USER is populated. You can use an
ISAPI Extension to forward the request to your Servlet Container at this
point, SANS the Authorization: NTLM header since it is no longer useful. You
can pass AUTH_USER value via any request header. You may even forward the
request using:
Authorization: Basic <Base64 Encoding of AUTH_USER>

I can tell you the one approach that won't work -- you cannot write an
ISAPI/CGI which merely passively captures and redirects NTLM traffic from
IIS to another server and then attempt to implement NTLM authentication on
that server. That is by definition a man-in-the-middle attack against the
protocol and thus thwarted by the authentication protocol.

What I am having you do is also a man-in-the-middle attack, but it is not
against the protocol but rather at the end point of the protocol (i.e. I'm
having you let IIS finish authentication and then independently fudge with
the details afterwards). You're not attacking the protocol and thus should
work.

--
//David
IIS
http://blogs.msdn.com/David.Wang
This posting is provided "AS IS" with no warranties, and confers no rights.
//

[quoted text, click to view]

David,

your comments are much appreciated. Just for completeness let me add
the following:

1. My ISAPI/CGI does NOT cause multiple Connection headers. It *may*
cause 1 Connection header, but if it does it is not an explicit event.
I did previously write that I tried adding a Connection: keep-alive
header in the servlet code - this was as a test to see if the existence
of a value for the connection header woulf prevent IIS from adding its
own Connection header.
2. Im not relying on firefox acting in the way it does - Im here in
this group trying to get my server implementation fixed!!!

What I was attempting to do was use anonymous access for the ISAPI
module and have all NTLM performed by the servlet container - I dont
see this as a violation of the protocol... So far this does not work
becuase either IIS or ISAPI inteferes with the headers - very
unfortunate, but there is now another way (see below)

Anyway, the AUTH_USER route is something to explore. I now understand
that this is set as an environment variable when IIS completes
authentication. Having just tried this I can get the remote user as
follows:

1. Set Integrated windows auth on my isapi module, unset anonymous
access.
2. Access page in servlet container, pick up AUTH_USER that is set
after NTLM negociation.

This is nice because I can change the authentication mechanism to
digest and it should all be transparent to my servlet container. OTOH,
there does seem to be a lot of NTLM going on as I browse the site (I
can see IIS periodically sending 401 headers back for both GET and POST
requests) - I'm not sure how this may affect performance, but it is
working, and Im happy!

thanks again

rgds
jim

Good to see that you came around to getting the solution I proposed to work
(as it should - it does not violate the authentication protocol and instead
works with it in the manner you wanted).

I have also explained why your original approach does not work, and you have
confirmed that it does not work... not certain what more I can say.

--
//David
IIS
http://blogs.msdn.com/David.Wang
This posting is provided "AS IS" with no warranties, and confers no rights.
//

[quoted text, click to view]