Your FAQ reads :
=============
11.14 How come Squid doesn't work with NTLM Authorization.
We are not sure. We were unable to find any detailed information on NTLM
(thanks Microsoft!), but here is our best guess:
Squid transparently passes the NTLM request and response headers between
clients and servers. The encrypted challenge and response strings most
likely encode the IP address of the client. Because the proxy is passing
these strings and is connected with a different IP address, the
authentication scheme breaks down. This implies that if NTLM authentication
works at all with proxy caches, the proxy would need to intercept the NTLM
headers and process them itself.
If anyone knows more about NTLM and knows the above to be false, please let
us know.
My comments :
===========
The company I work for has a product that acts as a security proxy on the
local machine. We had to make code modifications to get basic authentication
working. Regarding NTLM... we have yet to get this working, and are waiting
for a paying client to pay for this work.
I was the one responsible for investigating this...
Since our proxy runs on the same host as the web browser, then I think we
can rule out your explanation, i.e. request coming from a different IP
address than the proxied request. Must admit, I liked the idea when I read
it, it took two days of thinking about this old problem before I realised
why it didn't match my results.
It is interesting that Netscape can't support this either.... (or is it?)
I think that the incompatibity with proxies is to do with the logon security
identifier, the SID. We have always suspected that there might be some other
interaction between either IE / the OS with the web server / ms proxy that
is not carried out at the http level, could even be NetBIOS traffic. The SID
is probably being packaged as an ACE, which allows the server to have an
interactive session with the particular window / station /desktop making the
request. If it is engaging in a session with the window that made the
request then that needs to be the proxy.
I don't know if you guys are interested in supporting this... if you are I
am willing to help.
If you are interested, then here's what I would propose to do in order in
investigate it further.
* Place a target server behing a firewall with strict rules to only allow
http traffic on port 80 through, if this breaks NTLM then we know for sure
that something else is going on, the firewall logs should show the denied
requests.
* Setup windows station with socket watcher software to see exactly what
traffic goes between the client and server. See if this traffic is encrypted
or in the clear / examine contents.
* Given knowledge gained from above steps, see if NTLM is supportable.
Document the findings to remove the dark mystery surrounding NTLM.
Let me know what you think.
Regards,
-Enda
Received on Sat Nov 20 1999 - 10:21:09 MST
This archive was generated by hypermail 2.2.0 : Wed Apr 09 2008 - 12:01:56 MDT