On 24/10/2015 1:44 a.m., Keith White wrote:
> I changed around the DNS servers and still no luck. This also popped up in the log
>
> Acl.cc(70) AuthenticateAcl: returning 2 sending credentials to helper.
> 2015/10/23 05:41:35.259 kid1| 28,3| Acl.cc(158) matches: checked: AuthorizedUsers = -1 async
> 2015/10/23 05:41:35.259 kid1| 28,3| Acl.cc(158) matches: checked: http_access#3 = -1 async
> 2015/10/23 05:41:35.259 kid1| 28,3| Acl.cc(158) matches: checked: http_access = -1 async
> 2015/10/23 05:41:35.259 kid1| ERROR: NTLM Authentication validating user. Result: {result=BH, notes={message: NT_STATUS_UNSUCCESSFUL NT_STATUS_UNSUCCESSFUL; }}
> 2015/10/23 05:41:35.260 kid1| 29,5| UserRequest.cc(73) valid: Validated. Auth::UserRequest '0x12c1f10'.
>
IIRC that BH response happens when the helper gets a type-3 token
without having been part of the handshake dance that led up to it. The
helpers are stateful and the same one needs to be part of the whole
handshake.
That can happen if the connection is closed for some reasons after the
type-2 token is sent, and the client is brokenly continuing on a new
connection (Firefox is known to do that, others might too).
The connection is allowed to close after the initial 407 challenge. Some
clients are broken and require that to happen - which is where the
"auth_param ntlm keep_alive off" setting helps.
But not once the type-2 token is sent on the second 407. Squid should be
enforcing a persistent TCP connection from then onwards.
The nextstep is to look at either the HTTP messages or the TCP packet
level to find out what (if anything) is closing the connection between
the type-2 and type-3 token messages thats probably your problem.
Amos
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
