On 05/10/17 22:32, Grey wrote:
Firstly, thanks a lot for taking the time to check my configuration and
provide such detailed suggestions; I think I've followed all of them and
fixed the problems you pointed out.
We have a Windows domain and all those "all" directives where inherited from
our old proxy server (running Squid verson 3.1.20) and were used to let
domain users not receive any popups asking for credentials, while at the
same time presenting those credentials requests to non-domain users; if I'm
understanding your comments correctly I can safely remove them and get the
same result, am I right?
Most of the 'all' uses were pointless even in the old config. Only the
ones on the lines with AUTH and ProxyUsers ACLs had any effect on popups.
As for your requirement;
If you think about it Squid has zero ways to identify on-domain vs
off-domain users until *after* the user has logged in. Any on-domain
user who sends invalid or no credentials is indistinguishable from a
off-domain user sending invalid or no credentials.
So the config hack did not actually do what you were wanting in the
first place. It just suppresses login challenges for *everybody* without
credentials - as it was designed to do.
Popups are a feature of the client agent being used (aka Browser). The
browser may choose to do it at any time for any reason, though the
popular ones usually only do so if it cannot automatically locate any
credentials to send in response to a challenge.
Whatever was working was due to some other behaviour which may change at
any time regardless of the all hack use. Mostly likely by on-domain
clients sending their credentials up front before any need was mentioned
by the proxy.
FYI: The clients sending their users credentials without a challenge is
*very bad* security practice since they will broadcast those credentials
to anything they connect, not just your proxy.
We were having an issue with authentication too, where domain users
sometimes received a popup asking for credentials (shouldn't happen since I
have only enabled kerberos auth) and would need to click "Cancel" and reload
the page to resume browsing correctly; could the presence of all those "all"
directives have caused that too in your opinion?
The all-hack was preventing Squid from telling the browser what it
needed to login. So the popups themselves were caused by some other
reason unrelated to Squid.
That said, the absence of proper instructions from Squid probably was
involved with the horrible need to cancel and reload the page. The
normal behaviour would have been either silent re-try with other
automatic credentials or a popup that user could login with successfully.
FWIW: It is true that Kerberos tends to have popups less often than
NTLM. But that is just a side-effect of Kerberos being far more
efficient and less fragile than NTLM with its relatively static keytab
value - the NTLM equivalent of keytab is generated fresh on every single
TCP connection with a client connection to the DC, which takes up time
and can be interfered with. So the chance of problems leading to a popup
in Kerberos are far lower, but not gone completely.
The new configuration should result in this if I didn't miss/misunderstand
anything (I've addedd a whitelist rule that I missed earlier):
### TESTSQUID1 ###
http_port 3128
dns_v4_first on
pinger_enable off
netdb_filename none
error_default_language it
cache_mgr helpdesk@xxxxxxx
acl SSL_ports port 443
acl Safe_ports port 80 # http
acl Safe_ports port 21 # ftp
acl Safe_ports port 443 # https
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
auth_param negotiate program /usr/lib/squid/negotiate_kerberos_auth -r -d
auth_param negotiate children 150
auth_param negotiate children 150 startup=20 idle=10
auth_param negotiate keep_alive on
external_acl_type ProxyUser children-max=75 %LOGIN
/usr/lib/squid/ext_kerberos_ldap_group_acl -g INTERNET@TEST.LOCAL -D
TEST.LOCAL -S testldap
acl ProxyUser external ProxyUser
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow localhost
http_access deny manager
acl destsquid dstdomain .testsquid1 .testsquid2
http_access allow destsquid
acl siti_whitelist dstdomain "/etc/squid/siti_whitelist"
It should be obvious, but just so that it is clearly stated:
Anything which is allowed or denied regardless of user auth (eg the
whitelist?) should be done in an http_access line above the "deny !AUTH"
line.
acl AUTH proxy_auth REQUIRED
http_access deny !AUTH
http_access allow siti_whitelist
http_access allow ProxyUser
If you get unwanted popups after this config update, you can try adding
the all-hack back onto the above line.
http_access deny all
icap_enable on
icap_send_client_ip on
icap_send_client_username on
icap_client_username_encode off
icap_client_username_header X-Authenticated-User
icap_preview_enable on
icap_preview_size 1024
icap_service service_req reqmod_precache bypass=1
icap://testicap:1344/REQ-Service
adaptation_access service_req allow all
icap_service service_resp respmod_precache bypass=0
icap://testicap:1344/resp
adaptation_access service_resp allow all
coredump_dir /var/spool/squid
refresh_pattern ^ftp: 1440 20% 10080
refresh_pattern ^gopher: 1440 0% 1440
refresh_pattern -i (/cgi-bin/|\?) 0 0% 0
refresh_pattern . 0 20% 4320
Getting back to the main problem, i've set "icap_enable off" and reloaded
Squid, then tried again and got the same problem; since we're not using any
cache parent and Squid isn't using ICAP at the moment, can I assume there's
nothing else I can do and just have to ignore the problem?
The thing that bugs me is that only Chrome seems to be having this
particular problem... could this even be something linked to a bug or a
simple behaviour difference between Chrome and IE/Firefox?
Thanks again for all your patience :)
There is one other thing you can do. That is to enable "debug_options
11,2" for a while and run a test fetching with both browsers.
Squid-3.5 with that debug setting should log the HTTP request headers in
their on-wire format so you can compare what is going on in both client
and server connections for both browsers vs what the browsers think they
received.
That might give you some clues about things to workaround it. Just make
sure that workarounds are done as conservatively as possible so as not
to break other sites in other annoying ways.
Amos
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
