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
