I would like to shed some additional light that I recently uncovered.
According to this site
(http://msmvps.com/bradley/archive/2004/09/04/13009.aspx), the problem
is v5 of the Windows Update site and NTLM authenication for which I am
using. This particular article is addressing ISA Server and how to get
around the problem/bug. My question is, has anyone else been
successful in using NTLM under Squid (auth_param ntlm program
/usr/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp) and v5 of
Windows Update site? Is it possible in the acls to specify which to
use, basic or ntlm? I have both enabled as I also discovered recently
that there are other problems using NTLM such as against older version
of Java. In any case, I have both NTLM and basic enabled but can I
specify which authenication method to use against
http://v5.windowsupdate.microsoft.com?
On Wed, 6 Oct 2004 13:07:46 -0600, Adam Pearse <apearse@gmail.com> wrote:
> I know this topic has been asked many many times but I have not found
> a solution that works so I figured I would give it one last kick.
>
> Version 2.5.STABLE5
>
> You will notice I have tried a few things and left some of them
> commented in my squid.conf which is:
>
> acl all src 0.0.0.0/0.0.0.0
> #acl microsoft1 url_regex -i c.microsoft.com
> #acl microsoft2 url_regex -i download.microsoft.com
> #acl microsoft3 url_regex -i download.windowsupdate.com
> #acl microsoft4 url_regex -i v4.windowsupdate.microsoft.com
> #acl microsoft5 url_regex -i v5.windowsupdate.microsoft.com
> #acl microsoft6 url_regex -i windowsupdate.microsoft.com
> #acl microsoft7 url_regex -i www.download.windowsupdate.com
> #acl microsoft8 url_regex -i www.windowsupdate.com
> acl windowsupdate dstdomain .windowsupdate.microsoft.com
> acl AuthorizedUsers proxy_auth REQUIRED
> acl manager proto cache_object
> acl localhost src 127.0.0.1/255.255.255.255
> acl to_localhost dst 127.0.0.0/8
> acl SSL_ports port 443 563
> acl Safe_ports port 80 # http
> acl Safe_ports port 81 # Autorpm.org
> acl Safe_ports port 89 # Oracle Technical Forums
> acl Safe_ports port 21 # ftp
> acl Safe_ports port 443 563 # https, snews
> acl Safe_ports port 70 # gopher
> acl Safe_ports port 210 # wais
> acl Safe_ports port 1025-65535 # unregistered ports
> acl Safe_ports port 280 # http-mgmt
> acl Safe_ports port 488 # gss-http
> acl Safe_ports port 591 # filemaker
> acl Safe_ports port 777 # multiling http
> acl CONNECT method CONNECT
>
> http_access allow manager localhost
> http_access deny manager
> http_access deny !Safe_ports
> http_access deny CONNECT !SSL_ports
>
> #http_access allow microsoft1
> #http_access allow microsoft2
> #http_access allow microsoft3
> #http_access allow microsoft4
> #http_access allow microsoft5
> #http_access allow microsoft6
> #http_access allow microsoft7
> #http_access allow microsoft8
>
> no_cache deny windowsupdate
> http_access allow all AuthorizedUsers
> http_access allow localhost
> http_access deny all
>
> The problem seems to stem from the redirection of standard http over
> port 80 to https over 443. Microsoft seems to have a client side reg
> fix discussed in KB271361 which closes with this interesting tidbit:
>
> "You may have to use this registry key if you connect by using a proxy
> server that is handling secure and non-secure requests on the same
> server. One example of this behavior is the SQUID Proxy Server
> software. Because Internet Explorer typically caches port information,
> it may not send a secure request over the correct port number when it
> tries to send secure and non-secure responses to the same server, but
> on different port numbers."
>
> I tried the reg hack, that did not work either. I also increased my
> maximum_object_size to the following value:
> 1048576 KB (which should be big enough for any cab/exe coming from MS.
>
> Does anyone have a working squid configuration that actually allows
> Windows Updates to be successfully downloaded and installed via
> Internet Explorer?
>
> There is also a client side fix by Microsoft discussed in KB271361
> which has an interest
>
Received on Wed Oct 06 2004 - 13:39:49 MDT
This archive was generated by hypermail pre-2.1.9 : Mon Nov 01 2004 - 12:00:01 MST