Re: Problem with HAProxy + Squid 4.11 + Kerberos authentication

[Service MV <service.mv@xxxxxxxxx>]

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@MYDOMAIN.LOCAL
   5 1 HTTP/debian-proxy.mydomain.local@MYDOMAIN.LOCAL
   6 1 HTTP/debian-proxy.mydomain.local@MYDOMAIN.LOCAL
   7 1 host/DEBIAN-PROXY@MYDOMAIN.LOCAL
   8 1 host/DEBIAN-PROXY@MYDOMAIN.LOCAL
   9 1 host/DEBIAN-PROXY@MYDOMAIN.LOCAL
  10 1 host/debian-proxy.mydomain.local@MYDOMAIN.LOCAL
  11 1 host/debian-proxy.mydomain.local@MYDOMAIN.LOCAL
  12 1 host/debian-proxy.mydomain.local@MYDOMAIN.LOCAL
  13 2 HTTP/inet.mydomain.local@MYDOMAIN.LOCAL
  14 2 HTTP/inet@MYDOMAIN.LOCAL

global_defs {
    notification_email {
      some.user@mydomain.local
    }
    notification_email_from pxbalancer01@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@xxxxxxxxxxxx) 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@xxxxxxxxxxxxxxxxxxxxx> On Behalf Of Klaus Brandl
Sent: Friday, July 24, 2020 10:45 AM
To: squid-users@xxxxxxxxxxxxxxxxxxxxx
Subject: Re: 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@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users

_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users