[squid-users] Problem with HAProxy + Squid 4.11 + Kerberos authentication
Service MV
service.mv at gmail.com
Mon Jul 27 21:12:50 UTC 2020
Hi everybody!
I am just writing to thank you all for the excellent comments, you have
been very helpful.
I also take this opportunity to mention which operating model I decided to
use, which is working well so far.
DNS A and PTR record "balancer.mydomain.local" pointing to keepalived
virtual IP of HAProxy. This is my HA frontend.
Haproxy server in TCP mode.
The SQUID nodes joined to the domain and authenticated by Kerberos and LDAP.
In each SQUID node I added the credentials of the AD user account in the
keytab. I configured the AD user account 'without expiring the password'
and 'not requiring pre-authentication kerberos'.
If anyone wants or needs more information just let me know.
Best regards
Gabriel
squid.conf
visible_hostname debian-proxy.mydomain.local
http_port 3128 require-proxy-header
acl haproxy src 10.10.8.213
proxy_protocol_access allow haproxy
debug_options ALL, 1 33, 2 28, 9
maximum_object_size 8192 KB
error_directory /opt/squid411/share/errors/es-ar
shutdown_lifetime 0 seconds
forwarded_for transparent
auth_param negotiate program /usr/local/bin/squid_kerb_auth -i -r -s
GSS_C_NO_NAME
auth_param negotiate children 300 startup=150 idle=10
auth_param negotiate keep_alive on
auth_param basic program /opt/squid411/libexec/basic_ldap_auth -P -R -b
"dc=mydomain,dc=local" -D "cn=ldap,cn=Users,dc=mydomain,dc=local" -W
/opt/squid411/etc/ldappass.txt -f sAMAccountName=%s -h dc1.mydomain.local
auth_param basic children 30
auth_param basic realm Proxy Authentication
auth_param basic credentialsttl 4 hour
acl auth proxy_auth REQUIRED
http_access allow auth
acl SSL_ports port 443
acl Safe_ports port 80
acl CONNECT method CONNECT
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access deny all
haproxy.cfg
global
log /dev/log local0
log /dev/log local1 notice
chroot /var/lib/haproxy
stats socket /run/haproxy/admin.sock mode 660 level admin
stats timeout 30s
user haproxy
group haproxy
daemon
defaults
log global
mode tcp
option tcplog
option dontlognull
timeout connect 5000
timeout client 50000
timeout server 50000
frontend squid
bind 10.10.8.213:3128
default_backend squid_pool
backend squid_pool
balance source
mode tcp
option tcp-check
tcp-check connect port 3128
server squid1 10.10.8.205:3128 check inter 2000 rise 2 fall 3 send-proxy
server squid2 10.10.8.214:3128 check inter 2000 rise 2 fall 3 send-proxy
ktutil
read_kt /opt/squid411/etc/PROXY.keytab
list
1 1 DEBIAN-PROXY$@MYDOMAIN.LOCAL
2 1 DEBIAN-PROXY$@MYDOMAIN.LOCAL
3 1 DEBIAN-PROXY$@MYDOMAIN.LOCAL
4 1 HTTP/debian-proxy.mydomain.local at MYDOMAIN.LOCAL
5 1 HTTP/debian-proxy.mydomain.local at MYDOMAIN.LOCAL
6 1 HTTP/debian-proxy.mydomain.local at MYDOMAIN.LOCAL
7 1 host/DEBIAN-PROXY at MYDOMAIN.LOCAL
8 1 host/DEBIAN-PROXY at MYDOMAIN.LOCAL
9 1 host/DEBIAN-PROXY at MYDOMAIN.LOCAL
10 1 host/debian-proxy.mydomain.local at MYDOMAIN.LOCAL
11 1 host/debian-proxy.mydomain.local at MYDOMAIN.LOCAL
12 1 host/debian-proxy.mydomain.local at MYDOMAIN.LOCAL
13 2 HTTP/inet.mydomain.local at MYDOMAIN.LOCAL
14 2 HTTP/inet at MYDOMAIN.LOCAL
global_defs {
notification_email {
some.user at mydomain.local
}
notification_email_from pxbalancer01 at mydomain.local
smtp_server smtp.mydomain.local
smtp_connect_timeout 60
router_id pxbalancer01
}
vrrp_instance VI_1 {
state MASTER
interface eth0
virtual_router_id 114
priority 110
advert_int 1
authentication {
auth_type PASS
auth_pass SomePASS123
}
virtual_ipaddress {
10.10.8.213
}
virtual_routes {
10.10.8.0/22 via 10.10.8.207 src 10.10.8.213
}
}
El vie., 24 de jul. de 2020 a la(s) 06:44, Rafael Akchurin (
rafael.akchurin at diladele.com) escribió:
> Sorry forgot to add to Amos'es answer - use haproxy to handle *tcp*
> connections and let the sslbump/authentication run on the cluster of squids
> - thus you would get working auth on squid side and use keepalived/haproxy
> on the client side.
>
> I do not see any reason why it cannot work unless you specifically desire
> to use some haproxy's features for l7 loadbalancing.
>
> Best regards,
> Rafael Akchurin
> Diladele B.V.
>
> -----Original Message-----
> From: squid-users <squid-users-bounces at lists.squid-cache.org> On Behalf
> Of Klaus Brandl
> Sent: Friday, July 24, 2020 10:45 AM
> To: squid-users at lists.squid-cache.org
> Subject: Re: [squid-users] Problem with HAProxy + Squid 4.11 + Kerberos
> authentication
>
> Hi Brett,
>
> but then you have a single point of failure, if your loadbalancer is down,
> nothing will work. We need a solution, that each system can work by
> itself. So
> at the moment we merge the keytabs of each system together, and we are
> able to
> takeover the addresses of the other systems. Then we have no
> loadbalancing,
> but a fallback solution, what is more important on our systems.
>
> On Friday 24 July 2020 09:53:03 Brett Lymn wrote:
> > On Thu, Jul 23, 2020 at 06:07:39PM +0200, Klaus Brandl wrote:
> > > But if anyone knows a solution, i will spread my ears :)
> >
> > What we do is:
> >
> > 1) create a user account in AD that will be used for the HA front end,
> > set a password and export the keytab for this user
> > 2) Use ktadmin to import the keytab entries for the user created in step
> > 1 into the keytab for squid on the squid servers.
> > 3) Set a SPN (setspn) in AD that maps HTTP://ha.fqdn.address to the user
> > created in 1
> >
> > The SPN (service principal name) tells kerberos to use the user details
> > set up in step 1 to authenticate http requests. This works for us, has
> > been for years.
> >
> > One thing, if you want to know the IP addresses of your clients in the
> > squid logs you will need to do some extra stuff because all accesses
> > will appear to come from the HA loadbalancer. We have configured our
> > load balancers to insert the X-Forwarded-For header into the http
> > traffic and then modified the logging to log both the loadblancer and
> > client IP.
>
> Klaus
>
> ---
>
> genua GmbH
> Domagkstrasse 7, 85551 Kirchheim bei Muenchen
> tel +49 89 991950-0, fax -999, www.genua.de
>
> Geschaeftsfuehrer: Matthias Ochs, Marc Tesch
> Amtsgericht Muenchen HRB 98238
> genua ist ein Unternehmen der Bundesdruckerei-Gruppe.
> _______________________________________________
> squid-users mailing list
> squid-users at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users
> _______________________________________________
> squid-users mailing list
> squid-users at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20200727/11458cde/attachment-0001.htm>
More information about the squid-users
mailing list