Search squid archive

RE: Squid NTML and auth problems with POST

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxx] 
Sent: Tuesday, June 15, 2010 2:51 PM
To: squid-users@xxxxxxxxxxxxxxx
Subject: Re:  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



[Index of Archives]     [Linux Audio Users]     [Samba]     [Big List of Linux Books]     [Linux USB]     [Yosemite News]

  Powered by Linux