On 17/03/11 00:08, Marco Beck wrote:
> Hi,
>
> there is a known problem with certain Java applets (http(s) clients) when
> using NTLM authentication (see e.g. [1]). In Squid 2 a widely adopted
> workaround was to force basic authentication for those clients:
>
> acl javaNtlmFix browser -i java
> acl javaConnect method CONNECT
> header_access Proxy-Authenticate deny javaNtlmFix javaConnect
> header_replace Proxy-Authenticate Basic realm="foo"
>
> I don't get this to work in Squid 3. The 'header_access' option
> has been split into {request,reply}_header_access, and 'header_replace'
> seems to have been changed to only apply to request headers.
>
> Any ideas? I'm sure I'm missing something. I experimented with a
> couple of other options, but without getting the wanted result.
> Disabling authentication completely for Java applets isn't feasible
> (security policy). I did find a couple of similar reports on the
> mailing lists archives, but no solution AFAICT.
>
> We're running squid3-3.0.STABLE19 on SLES10-SP1. We could easily
> deploy custom RPMs built from e.g. a newer Squid version if there
> is a known solution.
>
AFAIK header_replace has only ever worked on request headers passing
through to some external server.
You want reply_header_access with the same logic to strip away
"Proxy-Authenticate: NTLM"
I have plans to add ACL testing to decide which auth types get added to
the challenge headers in the first place. For exactly this type of
restriction. But have no time to code it myself anytime soon. If you or
anyone wants to do the work and test it I'm happy to advise and mentor
the coding.
Amos
-- Please be using Current Stable Squid 2.7.STABLE9 or 3.1.11 Beta testers wanted for 3.2.0.5Received on Wed Mar 16 2011 - 11:49:24 MDT
This archive was generated by hypermail 2.2.0 : Thu Mar 17 2011 - 12:00:03 MDT