On 24/11/2012 8:52 p.m., Fuhrmann, Marcel wrote:
Hello Amos,
I've installed a test squid server. I'm using CentOS 6.3 (2GB Ram, 2 CPU, RAID10 for caching folder). I followed this guides:
http://serverfault.com/questions/66556/getting-squid-to-authenticate-with-kerberos-and-windows-2008-2003-7-xp
http://klaubert.wordpress.com/2008/01/09/squid-kerberos-authentication-and-ldap-authorization-in-active-directory/
And now i'm also using kerberos to authenticate to Windows 2008. And the best: It's working :-)
Here my config:
cache_mem 64 MB
cache_dir aufs /var/spool/squid 8000 256 256
cache_effective_user squid
cache_mgr lux.support@xxxxxx
cache_replacement_policy heap LFUDA
maximum_object_size 1000 KB
maximum_object_size_in_memory 128 KB
memory_replacement_policy heap GDSF
error_directory /usr/share/squid/errors/de-de
dns_nameservers 10.4.1.20
auth_param negotiate program /usr/lib64/squid/squid_kerb_auth
auth_param negotiate children 10
auth_param negotiate keep_alive on
acl snmplux snmp_community kj3v45hv345j23
#acl LAN src 10.4.1.0/24 10.2.1.0/24
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
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
acl AUTH proxy_auth REQUIRED
snmp_access allow snmplux localhost
http_access allow AUTH
The above line means authenticated users (any group or username - just
need to be accepted as valid by AD) are allowed unlimited access.
#http_access allow LAN
http_access allow manager localhost
http_access deny manager
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow localhost
http_access deny all
So localhost is the only source which is protected from making CONNECT
tunnels or requests to your manager interface.
I would move the allow AUTH line down next to the allow localhost line.
icp_access deny all
htcp_access deny all
hierarchy_stoplist cgi-bin ?
access_log /var/log/squid/access.log squid
cache_log /var/log/squid/cache.log 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
icp_port 0
http_port 3128
snmp_port 3401
Two questions about it:
How can I grant internet access to a ADS group called "INTERNET". The example in the guide doesn't work for me. If this is working, I will switch all my users to this server and discard my old one. Then I'm able to test, if this config is more efficient.
You need to check for auth, then to check group membership.
Your current form only grants access immeidately for all authenticated
users ("allow AUTH").
To ensure users are authenticated, but not to grant access immediately
use this form of auth test:
http_access deny !AUTH
Which means reject anyone not authenticated (Squid will use an auth
challenge in that rejection).
You then follow it with another access line sto tell Squid what to do
with the users who *are* authenticated. Such as yoru group check"
external_acl_type groups ...
acl groupCheck group INTERNET
http_access allow groupCheck
Is there any regulation how to arrange a squid config? OK, the rules need a special order to work correct, but what about the rest?
Multi-line options order of those multiple lines is very important in
how they act together. For the single line directives often placement is
less important, it only matters for the directives which depend on
something or something depends on them being set first (eg the
delay_pools count directive needs to be set before configuraing what
those pools are. 'acl' lines need to be set before any access control
which uses them, cache_peer label being defined before cache_peer_access
setup for it, etc, etc)
Amos
