RE: [squid-users] Squid NTML and auth problems with POST

On Tue, 15 Jun 2010 15:19:15 +0100, Nick Cairncross
<Nick.Cairncross_at_condenast.co.uk> wrote:
> Just to check, Amos: Squid 3 and above has client_persistent_connections
> and server_persistent_connections 'on' by default i.e. not required in
the
> conf file unless setting to 'off'...
>
> Correct?

Yes. (I mention because they are relevant and many still use older config
files with them explicitly off.)

The persistent_after_error was supposed to be on by default but was
recently found to be off for 3.1.4 and older releases.

Chances are it's the IE8 NTLM->Kerberos transition hitting you though.
That seems to be the biggest NTLM complaint in recent times.

Amos

>
> -----Original Message-----
> From: Amos Jeffries [mailto:squid3_at_treenet.co.nz]
> Sent: 15 June 2010 12:51
> To: squid-users_at_squid-cache.org
> Subject: Re: [squid-users] Squid NTML and auth problems with POST
>
> Dmitrijs Demidovs wrote:
>> Hi list!
>>
>> I have a problems with Squid and winbind auth.
>>
>> There is a couple of sites (internal CMS systems and external banking
>> sites) what have the same problems - users can not send attached data
>> files using html web forms (http POST method).
>>
>> We have Squid and Samba/winbind scheme what perform auth of users
>> against AD domain via NTLM.
>> Everything works just fine except this mystical POST problems.
>>
>> It looks like this:
>> ===
>> 1276593195.910 256 10.1.2.20 TCP_DENIED/407 4500 POST
>> http://www.site.com/admin.php? - NONE/- text/html
>> 1276593195.919 7 10.1.2.20 TCP_DENIED/407 4706 POST
>> http://www.site.com/admin.php? - NONE/- text/html
>> ===
>>
>> And if I make a hole in auth for POST method using:
>> ===
>> acl POST method POST
>> acl POST_whitelist dstdomain "/etc/squid/POST_whitelist.txt"
>> http_access allow POST POST_whitelist all ===
>>
>> and try to send file via form, then all is working fine again:
>> ===
>> 1276593290.237 438 10.1.2.20 TCP_MISS/200 6752 GET
>> http://www.site.com/admin.php? USER01 DEFAULT_PARENT/10.1.4.2 text/html
>> 1276593290.303 2 10.1.2.20 TCP_DENIED/407 4582 GET
>> http://www.site.com/n.php - NONE/- text/html
>> 1276593290.307 1 10.1.2.20 TCP_DENIED/407 4788 GET
>> http://www.site.com/n.php - NONE/- text/html
>> 1276593290.490 180 10.1.2.20 TCP_MISS/200 413 GET
>> http://www.site.com/n.php USER01 DEFAULT_PARENT/10.1.4.2 text/html
>> 1276593305.751 12342 10.1.2.20 TCP_MISS/302 817 POST
>> http://www.site.com/admin.php? - DEFAULT_PARENT/10.1.4.2 text/html
>> 1276593305.755 1 10.1.2.20 TCP_DENIED/407 4680 GET
>> http://www.site.com/admin.php? - NONE/- text/html
>> 1276593305.761 1 10.1.2.20 TCP_DENIED/407 4886 GET
>> http://www.site.com/admin.php? - NONE/- text/html
>> 1276593306.106 344 10.1.2.20 TCP_MISS/302 722 GET
>> http://www.site.com/admin.php? USER01 DEFAULT_PARENT/10.1.4.2 text/html
>> 1276593306.110 0 10.1.2.20 TCP_DENIED/407 4684 GET
>> http://www.site.com/admin.php? - NONE/- text/html
>> ===
>>
>>
>> I Googled this and have read a lot of forums, but the only thing that
>> I found jet, is that there is some king of "brain damage" in ntlm auth
>> scheme (it performs auth in a couple of iterations each time sending
more
>> and more of info about user, and this is fine fore GET but bad for
POST).
>>
>> Anyway, it seems that InternetExplorrer 8 (and Firefox 3 as well) do
not
>> performs additional auth iterations then they get first 407 while
POSTing
>> data.
>>
>> I been trying to overcome this problem by using squid configuration
>> directives like "auth_param ntlm keep_alive on/off", "no_cache" and
>> "ie_refresh on/off". Unfortunately - no luck for me :(
>
> keep_alive on is highly recommended for Squid older than 3.1. It should
be
> done by default in 3.1+, though I have not yet checked that.
>
> "no_cache" is useless for this. The "no_" part has been obsolete for
many
> years now. And POST data is not cached anyway.
>
> ie_refresh is a hack to get around broken refresh requests from old IE
> versions. It is only peripherally relevant, in that the refresh bug may
by
> some fluke cause connections to close early sometimes.
>
> NP: persistent_after_error needs to be set as well to help catch these
> ie_refresh error conditions.
>
>>
>> Is there any solution for this problem except "acl POST hole" I made?
>
> a) persistent_connections for both clients and servers is also
required.
> Your proxy appears to be closing the connection and thus requiring a
> re-auth when a new connection is opened for each request.
>
> b) not using NTLM. Negotiate/Kerberos works better and is recommended
over
> NTLM.
>
>
> You see this problem ONLY with IE8 and Firefox 3? not with older IE
> versions?
> Then chances are good those 'broken' IE8 and similar are sending
> Kerberos tokens instead of NTLM ones when challenged.
>
> Amos
Received on Wed Jun 16 2010 - 00:27:20 MDT