Re: [squid-users] Squid 3.1 NTLM Passthrough (SSO) to IIS with Firefox

Firefox on windows machines that are not in "the domain" by us only
worked properly when we switched it to using it's own NTLM
implementation instead of the native one, this is done by setting
network.auth.force-generic-ntlm to true

I am no big NTLM/AD guru (my field is the linux/unix machines in our
school), but from what I gleaned Mozilla encourages *not* using their
ntlm implementation since they see it as less secure than using the
native implementation, but I could be wrong here if anyone can
enlighten me I'd be happy :).

As far as I recall on a windows machine when using native NTLM and not
in the domain you also have to add the domain part in front of the
username because otherwise it sends the local machine name as the
'domain' (ie domain\username), but I think even with that it still
would continue to pop up when using native instead of mozilla.

I also have noticed that when using ntlm-auth on a client that is not
in the domain (windows/linux) you may be presented with multiple
authentication dialogs when you start to browse, my theory on that has
always been that the browser sent multiple request and squid replied
to each request with a 407 and since the browser doesn't have
authentication details yet it fires up a dialog for every 407
received.

Hopefully this was helpful, good luck,
Eli

2011/11/8 Bartschies, Thomas <Thomas.Bartschies_at_cvk.de>:
>
> Hi,
>
> I should add that were running squid NOT in transparent mode and that the proxy port is 8080 and NOT 80 as one may have guessed.
> I don't know any other firefox config settings than the ones I've already mentioned, with the exception of the network settings for
> kerberos authentication. The squid traces clearly show, that NTLM authentication is used, so kerberos shouldn't be relevant.
>
> Here is an excerpt from my config, without some access rules and acls. Even without the cache_peer, no change.
>
> acl manager proto cache_object
> acl localhost src 127.0.0.1/32
> acl to_localhost dst 127.0.0.0/8 0.0.0.0/32
> acl SSL_ports port 443 1025-65535 22
> acl Safe_ports port 80 81 83 85 # http
> acl Safe_ports port 21          # ftp
> acl Safe_ports port 443 22      # https, snews
> acl Safe_ports port 70          # gopher
> acl Safe_ports port 631         # cups
> 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
> http_access deny msnmessenger
> http_access deny to_localhost
> http_access allow localhost
> http_access allow manager localhost
> http_access deny !Safe_ports
> http_access deny CONNECT !SSL_ports
> http_access allow all
> cache_peer 10.x.x.x parent 8080 3130 no-query default
> auth_param basic children 5
> auth_param basic realm Squid proxy-caching web server
> auth_param basic credentialsttl 2 hours
> auth_param basic casesensitive off
> http_reply_access deny aim_http
> http_reply_access allow all
> icp_access allow localnet
> icp_access deny all
> htcp_access allow localnet
> htcp_access deny all
> http_port 8080 connection-auth=on
> hierarchy_stoplist cgi-bin ?
> cache_mem 500 MB
> cache_dir aufs /var/spool/squid 2000 16 256
> maximum_object_size 10000 KB
> ftp_list_width 64
> url_rewrite_children 15
> url_rewrite_access deny localhost
> refresh_pattern ^ftp:           1440    20%     10080
> refresh_pattern ^gopher:        1440    0%      1440
> refresh_pattern (cgi-bin|\?)    0       0%      0
> refresh_pattern .               0       20%     4320
> quick_abort_pct 95
> negative_dns_ttl 1 seconds
> request_header_access Accept-Encoding deny support.microsoft.com
> reply_header_access Accept-Encoding deny support.microsoft.com
> forward_timeout 15 minutes
> request_timeout 30 minutes
> shutdown_lifetime 10 seconds
> client_persistent_connections on
> server_persistent_connections on
> log_icp_queries off
> error_directory /usr/share/squid/errors/de
> always_direct allow local-intranet
> icap_enable off
> icap_preview_enable on
> icap_preview_size 128
> icap_send_client_ip on
> dns_nameservers 127.0.0.1 212.202.215.1 212.202.215.2
> ignore_unknown_nameservers off
> forwarded_for off
> pipeline_prefetch off
> ignore_expect_100 on
>
> Regards, Thomas
>
> -----Ursprüngliche Nachricht-----
> Von: Amos Jeffries [mailto:squid3_at_treenet.co.nz]
> Gesendet: Dienstag, 8. November 2011 13:45
> An: squid-users_at_squid-cache.org
> Betreff: Re: [squid-users] Squid 3.1 NTLM Passthrough (SSO) to IIS with Firefox
>
> On 9/11/2011 1:11 a.m., Bartschies, Thomas wrote:
>> Hi,
>>
>> our setup is:
>> Firefox 7.0.1, Squid 3.1.16 and Sharepoint Server on IIS.
>> In Firefox we've set already:
>> network.automatic-ntlm-auth.trusted-uris to the server address
>> network.automatic-ntlm-auth.allow-proxies = true (default)
>>
>> in squid.conf, we've tried some combinations of the following settings,
>> having the current settings this way:
>> client_persistent_connections on
>> server_persistent_connections on
>
> Right the above need to be on for NTLM to work properly.
>
>> pipeline_prefetch off
>>
>> Every time we try to connect to the sharepoint site, the browser
>> authentication box pops up. Even when we supply
>> correct credentials, the request for them pops up again. Making it
>> impossible to logon to the site.
>>
>> Internet Explorer 8/9 works fine. Google Chrome 15 also requests
>> credentials once and then logon works.
>>
>> First question is: Should this even work with Firefox, or is it known
>> not to?
>
> It is known to work as seamlessly as IE when setup properly.
>
> This sounds like
>
>>
>> If it should work, what other settings we've possibly missed?
>
> There is nothing special for Firefox. Since the other browsers are
> working fine (through the proxy?) it suggests a config issue setting up
> firefox.
>
>>
>> Connection pinning seems to be working, if I'm reading the traces
>> correctly. Sharepoint answers with HTTP Code 401.
>>
>> Our Proxy Setup is open. There are absolutely no client address
>> restrictions and we're also not using proxy authentication.
>> So there's not ntlm_auth helper in use.
>>
>> Kind regards,
>> Thomas
>
> Amos
>
Received on Tue Nov 08 2011 - 23:27:37 MST