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

From: Dmitrijs Demidovs <dmitrijs.demidovs_at_datakom.lv>
Date: Thu, 17 Jun 2010 12:10:54 +0300

Hi Amos,

Unfortunately setting "persistent_after_error on" (and other persistent_ client/server directives) did not solved the issue.
I also stripped off "ie_refresh" and "no_cache" + set back "keep_alive on".

Switcing to Kerberos auth is not a suitable solution for us at this moment.

:(

May be there is some other solution to try?

Thanks for help.

-----Original Message-----
From: Amos Jeffries [mailto:squid3_at_treenet.co.nz]
Sent: Tuesday, June 15, 2010 2:51 PM
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

-- 
Please be using
   Current Stable Squid 2.7.STABLE9 or 3.1.4
Received on Thu Jun 17 2010 - 09:11:06 MDT

This archive was generated by hypermail 2.2.0 : Thu Jun 17 2010 - 12:00:03 MDT