[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