On 27/04/2012 5:08 a.m., Wladner Klimach wrote:
Amos,
did you receive my e-mail? I really need to fix this problem. I've
been struggling for months to build a proxy solution and now the only
problem is this. So if you could point me some direction of what to do
I would appreciate.
There is nothing we can do about this.
The client software is pushing data into the CONNECT tunnel before the
NTLM handshake is completed, and sending RST in order to clear the
channel when it gets the handshake stage-2 response back. NTLM requires
that connections MUST be kept alive between stage 1 and stage 3 of the
handshake.
The client is just broken, it is already handling state knowledge that
NTLM is present and what stage the handshake is at, there is no reason
to send data on that second CONNECT and NTLM requires it not to.
Amos
Regards,
Wladner
2012/4/25 Wladner Klimach:
Amos,
I've made the capture as you said. I can see the CONNECT request from
the client and later the 407 Proxy Authentication Required, but after
that with no reason the client close the connection with a RST flag.
I'm sending you the file so that you can see the whole data flow. Can
you see something wrong at this captured data?
Regards,
Wladner
2012/4/20 Amos Jeffries:
On 21/04/2012 4:01 a.m., Wladner Klimach wrote:
Amos,
what could be causing this? When I desable NTLM authentication or when
I use Kerberos all access go just fine, but when only NTLM is able I
can't get access to https pages and I get in the logs TCP_DENIED/407.
How can I debug it?
You need to locate and identify what request headers are being denied.
The easiest way with 3.1 is a packet dump with full packet bodies ("tcpdump
-s0 ..."). Then base-64 decode the www-authenticate headers from the client
and check the type codes. NTLM has "NTLMSSPI" then a binary type number 1, 2
or 3.
The NTLM flow should be:
client: makes request (no auth)
Squid: emits 407 with NTLM advertised as available
squid: [optionally closes the connection (due to "auth_param ntlm
keep-alive off" hack)]
client: repeat request with type-1 NTLM proxy-auth header
squid: 407 with type-2 NTLM proxy-auth header
client: repeat request with type-3 NTLM proxy-auth header
squid: HTTP response
client: [optionally make other requests with type-3 NTLM proxy-auth header]
connection closes.
If you find connections opening and starting immediately with type-3 token
that is Kerberos or broken NTLM from the client.
Amos
regards
2012/4/20 Amos Jeffries<squid3@xxxxxxxxxxxxx>:
On 21/04/2012 1:15 a.m., Harry Mills wrote:
Hi Wladner,
I don't think this is causing your problems, but I think you need to
change the following:
Instead of:
http_access deny CONNECT !Safe_ports
try:
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
Also, on the last two lines of your included config you have:
acl AUTENTICADO proxy_auth REQUIRED
http_access allow AUTENTICADO
This is one of several correct proxy-auth configurations.
I simply have:
http_access allow proxy_auth
I have no idea if this will help, but worth giving it a try perhaps?
?? for that to work you require this somewhere above your http_access
rule
...
acl proxy_auth proxy_auth REQUIRED
or some other definition for an ACL *label* "proxy_auth".
Amos
