<div dir="ltr">No suggestions?</div><div class="gmail_extra"><br><div class="gmail_quote">2015-12-07 14:57 GMT+01:00 Fabio Bucci <span dir="ltr"><<a href="mailto:fabietto82@gmail.com" target="_blank">fabietto82@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Thanks Amos.<div>So, what do you suggest? Implement kerberos authetication instead NTLM one?</div><div><br></div><div>I have to check if netscaler is able to perform that kind hack you wrote before.</div><div><br></div><div>Thanks again,</div><div>Fabio</div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">2015-12-05 7:22 GMT+01:00 Amos Jeffries <span dir="ltr"><<a href="mailto:squid3@treenet.co.nz" target="_blank">squid3@treenet.co.nz</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 5/12/2015 5:39 a.m., Fabio Bucci wrote:<br>
> Thanks Amos.<br>
> Actually my load balancing is configured to perform round robin balancing<br>
> between the two nodes. I added a session persistance by source ip in order<br>
> to avoid to login again with some sites.<br>
><br>
> my squid.conf is very simple:<br>
> auth_param ntlm program /usr/bin/ntlm_auth<br>
> --helper-protocol=squid-2.5-ntlmssp<br>
> auth_param ntlm children 100<br>
> auth_param ntlm keep_alive off<br>
><br>
> acl auth proxy_auth REQUIRED<br>
><br>
> http_access allow auth<br>
><br>
<br>
</span>Okay. That *should* work. With some NTLM-specific caveats.<br>
<span><br>
<br>
> forwarded_for on<br>
> follow_x_forwarded_for allow netscaler<br>
><br>
<br>
</span>If the LB is touching the traffic enough to add headers then it is a<br>
proxy. NTLM does not work at all well through proxies. NTLM as a whole<br>
is based on the assumption that there is one (and only one) TCP<br>
connection between it and the proxy - the credentials are tied to the<br>
TCP connection state.<br>
<br>
There is one VERY slim hack that lets NTLM pass straight through a<br>
frontend proxy/LB. That is by pinning the LB's inbound and outbound TCP<br>
connections together. This is not just session persistence, but absolute<br>
prohibition on any other traffic (even from other connections by the<br>
same client) being sent to that outbound LB->proxy connection. Some LB<br>
can do it, some can't.<br>
<br>
<br>
I recommend advertising both/all proxy IPs to the clients and letting<br>
each select the one(s) it wants to contact. That way the client can<br>
perform NTLM directly to the Squid.<br>
<br>
<br>
On the other hand NTLM was deprecated back in 2006, you should try<br>
migrating to Negotiate/Kerberos. Kerberos is a bit of a learning curve<br>
and can be tricky working with older client software. But is *way* more<br>
efficient and friendlier to HTTP (but still not fully).<br>
<div><div><br>
<br>
Amos<br>
<br>
_______________________________________________<br>
squid-users mailing list<br>
<a href="mailto:squid-users@lists.squid-cache.org" target="_blank">squid-users@lists.squid-cache.org</a><br>
<a href="http://lists.squid-cache.org/listinfo/squid-users" rel="noreferrer" target="_blank">http://lists.squid-cache.org/listinfo/squid-users</a><br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>