-----Original Message----- From: Willy Tarreau Sent: Wednesday, December 05, 2012 8:13 AM To: David Touzeau Cc: [email protected] Subject: Re: NTLM/Issues With HaProxy to SQUID need help...
Hi David, [ your MUA still emits those Ctrl-M at the end of each line ] On Tue, Dec 04, 2012 at 11:09:09PM +0100, David Touzeau wrote: > HI all > > > I have 3 Squid servers connected to my Active Directory (about 1500 users) > > I have setup HaProxy to balance connections from users to the 3 squid servers > in order to go Internet. > > > When connecting browsers trough HaProxy: > > -------------------------------------------------------------------------------- > > When starting the browser, Squid Proxy display an authentication popup in > order to access to internet. > > It seems the NTLM Windows session did not pass trough HaProxy. > > > When connecting browsers directly to one of the 3 squid servers: > > -------------------------------------------------------------------------------- > > No authentication popup is displayed and NTLM session is correctly sended to > Squid Proxy. > > > I would like to know if there a tip/suggestion to let HaProxy pass NTLM > authentication ? The problem with NTLM-based auth is that it's broken by design, and even documented as such. I'm always amazed that people continue to try to use it, because it's clearly documented that NTLM auth can only work when the authenticating server owns a DIRECT connection to the client. Not only it does not work in other cases, but it's a major security issue to use it that way, because if the auth succeeds, there is a risk that several users share the same connection with the authenticated user's credentials (and I used to confirm this in the past, it's very funny, if you're the user). The problem is that NTLM authenticates the CONNECTION and not requests. As soon as you have proxies, reverse proxies, load balancers, etc... in the chain, the connection may be shared by anybody. For more pointers on the breakage in the NTLM spec : http://tools.ietf.org/html/rfc4559 (click "Errata" at top) http://www.rfc-editor.org/errata_search.php?rfc=4559 The "Negotiate" authentication scheme violates basic HTTP principles, in that it attaches information to the connection on which the handshake happened, and furthermore uses syntax in the WWW-Authenticate and Authorization header fields that is in violation of the base ABNF definitions. http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-21#page-11 HTTP is defined as a stateless protocol, meaning that each request message can be understood in isolation. Many implementations depend on HTTP's stateless design in order to reuse proxied connections or dynamically load balance requests across multiple servers. Hence, servers MUST NOT assume that two requests on the same connection are from the same user agent unless the connection is secured and specific to that agent. Some non-standard HTTP extensions (e.g., [RFC4559]) have been known to violate this requirement, resulting in security and interoperability problems. In your case, what is happening is that haproxy receives a connection from a client, squid responds with a challenge that haproxy transmits to the client, then haproxy closes the server connection, and when the client reposts the request with the challenge, haproxy establishes a new connection to squid, which is not the same as previous one, so the challenge fails. If you are certain that your clients *DIRECTLY* connect to haproxy, you can make haproxy work in tunnel mode. It will then only check the first request of each connection, forward to squid and keep the connection active without analyzing it anymore. That way, the client will be able to forward his challenge response to squid. You'll obviously miss logs, and you won't be able to apply useful load balancing algorithms (eg: no URL hash to improve cache hit ratio). When using tunnel mode, you should use the leastconn LB algo. To use this mode, remove any "httpclose", "forceclose" and "http-server-close" options. Hoping this helps, Willy Thanks Willy for this clarification but if i turn to tunnel mode,did i lose the x-forwarded-for HTTP header ?
