On Tue, 15 Jun 2010 15:19:15 +0100, Nick Cairncross <Nick.Cairncross@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxx] > Sent: 15 June 2010 12:51 > 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
