Problem with HAProxy + Squid 4.11 + Kerberos authentication

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

Problem with HAProxy + Squid 4.11 + Kerberos authentication

neok
Hi, everybody.
I have a SQUID 4.11 compiled on Debian 9.8 with kerberos integration authenticating and browsing without problems:
cache.log
squid_kerb_auth: User some.user authenticated
access.log
10.10.10.203 TCP_TUNNEL/200 5264 CONNECT update.googleapis.com:443 some.user HIER_DIRECT/172.217.162.3 -

The problem starts when I try to configure a HAProxy 1.8 load balancer to which by redundancy I configured a virtual IP with the keepalived service. When I point my browser to the DNS A record (balancer.mydomain.local) which in turn points to the keepalived virtual IP, the authentication stops working:
cache.log
no records
access.log
10.10.8.207 TCP_DENIED/407 4142 CONNECT update.googleapis.com:443 - HIER_NONE/- text/

In the client browser a prompt appears requesting authentication.

I find it strange that the IP registered by SQUID is 10.10.8.207, which is the physical IP of my VM, instead of the virtual IP configured in HAProxy, which is the IP 10.10.8.213.

I send you all the configurations that I have made to see if you can help me to find where my configuration error is.

keepalived.conf
  global_defs {
     notification_email {
       [hidden email]
     }
     notification_email_from [hidden email]
     smtp_server smtp. mydomain.local
     smtp_connect_timeout 60
  }

  vrrp_instance VI_1 {
      state MASTER
      interface eth0
      virtual_router_id 101
      priority 101
      advert_int 1
      authentication {
          auth_type PASS
          auth_pass somepass123
      }
      virtual_ipaddress {
          10.10.8.213
      }
  }


haproxy.conf
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
maxconn 4000
ca-base /etc/ssl/certs
crt-base /etc/ssl/private
server=haproxy
ssl-default-bind-ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:RSA+AESGCM:RSA+AES:!aNULL:!MD5:!DSS
ssl-default-bind-options no-sslv3

defaults
balance source
log global
mode http
option httplog
option dontlognull
option http-server-close
option forwardfor except 127.0.0.0/8
timeout connect 5000
timeout client 50000
timeout server 50000

errorfile 400 /etc/haproxy/errors/400.http
errorfile 403 /etc/haproxy/errors/403.http
errorfile 408 /etc/haproxy/errors/408.http
errorfile 500 /etc/haproxy/errors/500.http
errorfile 502 /etc/haproxy/errors/502.http
errorfile 503 /etc/haproxy/errors/503.http
errorfile 504 /etc/haproxy/errors/504.http

### statistics
listen stats
bind 10.10.8.213:1936
mode http
stats enable
stats hide-version
stats realm Haproxy\ Statistics
stats uri /haproxy?stats
stats auth haproxy:somepass123

### balancer
listen squid
bind 10.10.8.213:3128
  mode http
  option httplog
  balance source
  hash-type consistent
  option httpclose
  cookie SERVERID insert indirect nocache
  option forwardfor header X-Client
  server proxy1 10.10.8.205:3128 check inter 2000 rise 2 fall 5
  server proxy2 10.10.8.206:3128 check inter 2000 rise 2 fall 5


squid.conf
# minimal configuration for testing
visible_hostname proxy1.mydomain.local
http_port 3128
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 on
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
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


squid -v
Squid Cache: Version 4.11
Service Name: squid

This binary uses OpenSSL 1.0.2u  20 Dec 2019. For legal restrictions on distribution see https://www.openssl.org/source/license.html

configure options:  '--prefix=/opt/squid411' '--includedir=/include' '--mandir=/share/man' '--infodir=/share/info' '--localstatedir=/opt/squid411/var' '--disable-maintainer-mode' '--disable-dependency-tracking' '--disable-silent-rules' '--enable-inline' '--enable-async-io' '--enable-storeio=ufs,aufs,diskd' '--enable-removal-policies=lru,heap' '--enable-delay-pools' '--enable-cache-digests' '--enable-underscores' '--enable-icap-client' '--enable-follow-x-forwarded-for' '--enable-auth' '--enable-digest-auth-helpers' '--enable-negotiate-auth-helpers' '--enable-auth-ntlm' '--enable-arp-acl' '--enable-esi--disable-translation' '--with-logdir=/var/log/squid411' '--with-pidfile=/var/run/squid411.pid' '--with-filedescriptors=65536' '--with-large-files' '--with-default-user=proxy' '--enable-linux-netfilter' '--enable-ltdl-convenience' '--with-openssl' '--enable-ssl' '--enable-ssl-crtd'


env
KRB5_KTNAME=/opt/squid411/etc/PROXY.keytab
KRB5RCACHETYPE=none


/etc/krb5.conf
[libdefaults]
    default_realm = MYDOMAIN.LOCAL
    dns_lookup_kdc = yes
    dns_lookup_realm = yes
    ticket_lifetime = 24h

        default_tgs_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5
        default_tkt_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5
        permitted_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5

[realms]
    MYDOMAIN.LOCAL = {
        kdc = s-dc00.mydomain.local
        kdc = s-dc01.mydomain.local
        kdc = s-dc02.mydomain.local
        admin_server = s-dc00.mydomain.local
    }

[domain_realm]
    .mydomain.local = MYDOMAIN.LOCAL
    mydomain.local = MYDOMAIN.LOCAL


msktutil -c -b "OU=SERVIDORES" -s HTTP/debian-proxy.mydomain.local -k /opt/squid411/etc/PROXY.keytab --computer-name DEBIAN-PROXY --upn HTTP/debian-proxy.mydomain.local --server s-dc00.mydomain.local --verbose --enctypes 28


# permissions for kaytab file
chgrp proxy /opt/squid411/etc/PROXY.keytab
chmod g+r /opt/squid411/etc/PROXY.keytab


klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: [hidden email]

Valid starting       Expires              Service principal
07/23/2020 11:59:45  07/23/2020 21:59:45  krbtgt/[hidden email]
        renew until 07/24/2020 11:59:40


One thing I didn't quite understand is the procedure to authenticate from HAProxy. According to the documentation I read, I did the following:

I created a DNS A record and its PTR in my DNS server pointing to the virtual IP of the keepalived (10.10.8.213) in the HAProxy. 
Then I created a "HTTP_inet" user account in Active Directory.
Then on my domain controller, in a CMD with administrator permissions, I ran:
setspn -S HTTP/inet.mydomain.local HTTP_inet
setspn -S HTTP/inet HTTP_inet
In both cases the message was: object updated.
Then in my SQUID servers, I executed:
kinit [hidden email]
It asks for the user's password.
Start the ktutil tool
That's where I write:
addent -password -p HTTP/inet.mydomain.local -k 2 -e rc4-hmac
Ask the user password
addent -password -p HTTP/inet -k 2 -e rc4-hmac
Ask the user password
wkt /opt/squid411/etc/PROXY.keytab
quit

list the keys in keytab:
ktutil
read_kt /opt/squid411/etc/PROXY.keytab
   1 1 DEBIAN-PROXY$@MYDOMAIN.LOCAL
   2 1 DEBIAN-PROXY$@MYDOMAIN.LOCAL
   3 1 DEBIAN-PROXY$@MYDOMAIN.LOCAL
   4 1 HTTP/[hidden email]
   5 1 HTTP/[hidden email]
   6 1 HTTP/[hidden email]
   7 1 host/[hidden email]
   8 1 host/[hidden email]
   9 1 host/[hidden email]
  10 1 host/[hidden email]
  11 1 host/[hidden email]
  12 1 host/[hidden email]
  13 2 HTTP/[hidden email]
  14 2 HTTP/[hidden email]

It's this last part I understand the least, maybe the mistake is there. Or somewhere else.
I appreciate any help you can offer me.

Best regards,

Gabriel


_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Problem with HAProxy + Squid 4.11 + Kerberos authentication

Klaus Brandl
Hi Gabriel,

same problem here on our HA systems.
I think, this is caused by kerberos overall, the tickets are always bound to
the hosts realname and address, look at "klist" on your client, and only
exactly this name could be used as proxy entry.

But if anyone knows a solution, i will spread my ears :)

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
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Problem with HAProxy + Squid 4.11 + Kerberos authentication

neok
Hi Klaus,
I think something similar. But I understand that you can use the Kerberos delegation in AD. That's partly why I'm not convinced by the documentation I read, which tells me to create a user account in Active Directory. And I don't understand what a user account has to do here. Maybe the documentation is wrong and actually refers to a computer account, and the operation of adding a Service Principal Name should be done to the computer object. I don't know. But I'm going to try to do it and see what I can achieve.

I'll be back.

El jue., 23 de jul. de 2020 a la(s) 13:16, Klaus Brandl ([hidden email]) escribió:
Hi Gabriel,

same problem here on our HA systems.
I think, this is caused by kerberos overall, the tickets are always bound to
the hosts realname and address, look at "klist" on your client, and only
exactly this name could be used as proxy entry.

But if anyone knows a solution, i will spread my ears :)

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
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Problem with HAProxy + Squid 4.11 + Kerberos authentication

Brett Lymn-2
In reply to this post by Klaus Brandl
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.

--
Brett Lymn
This email has been sent on behalf of one of the following companies within the BAE Systems Australia group of companies:

BAE Systems Australia Limited - Australian Company Number 008 423 005
BAE Systems Australia Defence Pty Limited - Australian Company Number 006 870 846
ASC Shipbuilding Pty Limited - Australian Company Number 051 899 864

BAE Systems Australia's registered office is Evans Building, Taranaki Road, Edinburgh Parks, Edindurgh, South Australia, 5111.
ASC Shipbuilding's registered office is Level 2, 80 Flinders Street, Adelaide, South Australia, 5000.
If the identity of the sending company is not clear from the content of this email, please contact the sender.

This email and any attachments may contain confidential and legally privileged information. If you are not the intended recipient, do not copy or disclose its content, but please reply to this email immediately and highlight the error to the sender and then immediately delete the message.

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Problem with HAProxy + Squid 4.11 + Kerberos authentication

Amos Jeffries
Administrator
In reply to this post by neok
On 24/07/20 5:09 am, Service MV wrote:

> Hi Klaus,
> I think something similar. But I understand that you can use the
> Kerberos delegation in AD. That's partly why I'm not convinced by the
> documentation I read, which tells me to create a user account in Active
> Directory. And I don't understand what a user account has to do here.
> Maybe the documentation is wrong and actually refers to a computer
> account, and the operation of adding a Service Principal Name should be
> done to the computer object. I don't know. But I'm going to try to do it
> and see what I can achieve.
>

Kerberos authentication in HTTP uses the Negotiate scheme. The model for
that scheme is that it authenticates the exact TCP connection over which
the credentials are transmitted.

So for it to work *through* a proxy (eg HAProxy) that proxy must ensure
the *two* TCP connections it is handling (from-client and to-Squid) are
pinned together with all HTTP multiplexing features disabled _and_ the
Proxy-Auth* headers are not touched or used along the way.

 => If either of those conditions is broken the auth will not work and
users will definitely get the behaviour you are seeing. That behaviour
may also occur anyway if later stages are broken - this is just the
first and most non-obvious problem for beginners.


[ below is simplified a bit/lot to ensure you have the basic
understanding. There is a steep learning curve for Kerberos tools and
one needs basics before troubleshooting exposes the gory details ]

The HTTP agent which is doing the Kerberos auth validation (eg Squid)
must be configured with an account that can perform authentication tasks
with the central domain server.
 This can be either User or Machine account as you know. The important
difference is their policy on passwords. User accounts need password
rotation, machines are effectively permanent. Since keytab used by Squid
has to be re-generated every time the account password changes User
accounts are naturally far more complex to administrate for reliable auth.

 => So ... your choice and YMMV. But we recommend a machine account
unless you have reason to go the more complex way.


At the other end the client software needs a keytab with a "Principal"
name telling it what to request from the central domain server when it
needs a token that Squid can validate.

 => The principal name has to match up with the account details used by
the proxy which is checking the auth credentials. This is why the middle
proxy (eg HAProxy) cannot touch the authentication on its way to Squid.

 => The principal name is also case-sensitive and and must survive
*exact* string comparisons despite DNS resolve being involved [ because
reasons :( ].  So be sure to use full FQDN rather than host name
abbreviations.



> I'll be back.
>
> El jue., 23 de jul. de 2020 a la(s) 13:16, Klaus Brandl escribió:
>
>     Hi Gabriel,
>
>     same problem here on our HA systems.
>     I think, this is caused by kerberos overall, the tickets are always
>     bound to
>     the hosts realname and address, look at "klist" on your client, and
>     only
>     exactly this name could be used as proxy entry.


Indeed. Use of wrong names (eg not using the full FQDN), wrong case, or
the hostnames not being DNS resolvable are common causes of Kerberos not
working.


Amos

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Problem with HAProxy + Squid 4.11 + Kerberos authentication

Klaus Brandl
In reply to this post by Brett Lymn-2
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
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Problem with HAProxy + Squid 4.11 + Kerberos authentication

L.P.H. van Belle
In reply to this post by neok
i would recommend to ..
1) use debian buster,
2) use squid 4.12
3) use samba (winbind).
 
needed  in smb.conf ( only shown whats really needed ), there is more offcourse.

    dedicated keytab file = /etc/krb5.keytab
    kerberos method = secrets and keytab
 
    # renew the kerberos ticket
    winbind refresh tickets = yes
    # Added for freeradius support
    #ntlm auth = mschapv2-and-ntlmv2-only

apt install winbind krb5-user should be sufficient.

samba joins the domain.
/etc/krb5.keytab contains the default part and refreshed the server kerberos passworks/tickes.

And for squid its keytab.

kinit Administrator
export KRB5_KTNAME=FILE:/etc/squid/HTTP-$(hostname -s).keytab
net ads keytab add_update_ads HTTP/$(hostname -f) -U Administrator

# alias name to keytab
net ads keytab ADD HTTP/CNAME.FQDN 

# check keytab file.
klist -ke /etc/squid/HTTP-$(hostname -s).keytab
unset KRB5_KTNAME

# set rights.
chgrp proxy /etc/squid/HTTP-$(hostname -s).keytab
chmod g+r /etc/squid/HTTP-$(hostname -s).keytab

And i use  in squid
auth_param negotiate program /usr/lib/squid/negotiate_wrapper_auth \
    --kerberos /usr/lib/squid/negotiate_kerberos_auth -k /etc/squid/HTTP-hostname.keytab \
    -s [hidden email] -s [hidden email]
    --ntlm /usr/bin/ntlm_auth --helper-protocol=gss-spnego --domain=NTDOM

Point to think about.

server IP's needs A + PTR 
use CNAMEs in the DNS.
and make sure the resolving is setup correctly.

Add a caching DNS to the proxy. ( and let squid use it also )

I had this working (without HAproxy) but with keepalived.

As far i can tel, your problem is in how the hostnames and ip are used. 
but above might give you ideas.

Greetz,

Louis

 


Van: squid-users [mailto:[hidden email]] Namens Service MV
Verzonden: donderdag 23 juli 2020 17:36
Aan: [hidden email]
Onderwerp: [squid-users] Problem with HAProxy + Squid 4.11 + Kerberos authentication

Hi, everybody.
I have a SQUID 4.11 compiled on Debian 9.8 with kerberos integration authenticating and browsing without problems:
cache.log
squid_kerb_auth: User some.user authenticated
access.log
10.10.10.203 TCP_TUNNEL/200 5264 CONNECT update.googleapis.com:443 some.user HIER_DIRECT/MailScanner warning: numerical links are often malicious: MailScanner warning: numerical links are often malicious: 172.217.162.3 -

The problem starts when I try to configure a HAProxy 1.8 load balancer to which by redundancy I configured a virtual IP with the keepalived service. When I point my browser to the DNS A record (balancer.mydomain.local) which in turn points to the keepalived virtual IP, the authentication stops working:
cache.log
no records
access.log
10.10.8.207 TCP_DENIED/407 4142 CONNECT update.googleapis.com:443 - HIER_NONE/- text/

In the client browser a prompt appears requesting authentication.

I find it strange that the IP registered by SQUID is 10.10.8.207, which is the physical IP of my VM, instead of the virtual IP configured in HAProxy, which is the IP 10.10.8.213.

I send you all the configurations that I have made to see if you can help me to find where my configuration error is.

keepalived.conf
  global_defs {
     notification_email {
       [hidden email]
     }
     notification_email_from [hidden email]
     smtp_server smtp. mydomain.local
     smtp_connect_timeout 60
  }

  vrrp_instance VI_1 {
      state MASTER
      interface eth0
      virtual_router_id 101
      priority 101
      advert_int 1
      authentication {
          auth_type PASS
          auth_pass somepass123
      }
      virtual_ipaddress {
          10.10.8.213
      }
  }


haproxy.conf
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
maxconn 4000
ca-base /etc/ssl/certs
crt-base /etc/ssl/private
server=haproxy
ssl-default-bind-ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:RSA+AESGCM:RSA+AES:!aNULL:!MD5:!DSS
ssl-default-bind-options no-sslv3

defaults
balance source
log global
mode http
option httplog
option dontlognull
option http-server-close
option forwardfor except MailScanner warning: numerical links are often malicious: MailScanner warning: numerical links are often malicious: 127.0.0.0/8
timeout connect 5000
timeout client 50000
timeout server 50000

errorfile 400 /etc/haproxy/errors/400.http
errorfile 403 /etc/haproxy/errors/403.http
errorfile 408 /etc/haproxy/errors/408.http
errorfile 500 /etc/haproxy/errors/500.http
errorfile 502 /etc/haproxy/errors/502.http
errorfile 503 /etc/haproxy/errors/503.http
errorfile 504 /etc/haproxy/errors/504.http

### statistics
listen stats
bind MailScanner warning: numerical links are often malicious: MailScanner warning: numerical links are often malicious: 10.10.8.213:1936
mode http
stats enable
stats hide-version
stats realm Haproxy\ Statistics
stats uri /haproxy?stats
stats auth haproxy:somepass123

### balancer
listen squid
bind MailScanner warning: numerical links are often malicious: MailScanner warning: numerical links are often malicious: 10.10.8.213:3128
  mode http
  option httplog
  balance source
  hash-type consistent
  option httpclose
  cookie SERVERID insert indirect nocache
  option forwardfor header X-Client
  server proxy1 MailScanner warning: numerical links are often malicious: MailScanner warning: numerical links are often malicious: 10.10.8.205:3128 check inter 2000 rise 2 fall 5


squid.conf
# minimal configuration for testing
visible_hostname proxy1.mydomain.local
http_port 3128
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 on
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
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


squid -v
Squid Cache: Version 4.11
Service Name: squid

This binary uses OpenSSL 1.0.2u  20 Dec 2019. For legal restrictions on distribution see https://www.openssl.org/source/license.html

configure options:  '--prefix=/opt/squid411' '--includedir=/include' '--mandir=/share/man' '--infodir=/share/info' '--localstatedir=/opt/squid411/var' '--disable-maintainer-mode' '--disable-dependency-tracking' '--disable-silent-rules' '--enable-inline' '--enable-async-io' '--enable-storeio=ufs,aufs,diskd' '--enable-removal-policies=lru,heap' '--enable-delay-pools' '--enable-cache-digests' '--enable-underscores' '--enable-icap-client' '--enable-follow-x-forwarded-for' '--enable-auth' '--enable-digest-auth-helpers' '--enable-negotiate-auth-helpers' '--enable-auth-ntlm' '--enable-arp-acl' '--enable-esi--disable-translation' '--with-logdir=/var/log/squid411' '--with-pidfile=/var/run/squid411.pid' '--with-filedescriptors=65536' '--with-large-files' '--with-default-user=proxy' '--enable-linux-netfilter' '--enable-ltdl-convenience' '--with-openssl' '--enable-ssl' '--enable-ssl-crtd'


env
KRB5_KTNAME=/opt/squid411/etc/PROXY.keytab
KRB5RCACHETYPE=none


/etc/krb5.conf
[libdefaults]
    default_realm = MYDOMAIN.LOCAL
    dns_lookup_kdc = yes
    dns_lookup_realm = yes
    ticket_lifetime = 24h

        default_tgs_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5
        default_tkt_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5
        permitted_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5

[realms]
    MYDOMAIN.LOCAL = {
        kdc = s-dc00.mydomain.local
        kdc = s-dc01.mydomain.local
        kdc = s-dc02.mydomain.local
        admin_server = s-dc00.mydomain.local
    }

[domain_realm]
    .mydomain.local = MYDOMAIN.LOCAL
    mydomain.local = MYDOMAIN.LOCAL


msktutil -c -b "OU=SERVIDORES" -s HTTP/debian-proxy.mydomain.local -k /opt/squid411/etc/PROXY.keytab --computer-name DEBIAN-PROXY --upn HTTP/debian-proxy.mydomain.local --server s-dc00.mydomain.local --verbose --enctypes 28


# permissions for kaytab file
chgrp proxy /opt/squid411/etc/PROXY.keytab
chmod g+r /opt/squid411/etc/PROXY.keytab


klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: [hidden email]

Valid starting       Expires              Service principal
07/23/2020 11:59:45  07/23/2020 21:59:45  krbtgt/[hidden email]
        renew until 07/24/2020 11:59:40


One thing I didn't quite understand is the procedure to authenticate from HAProxy. According to the documentation I read, I did the following:

I created a DNS A record and its PTR in my DNS server pointing to the virtual IP of the keepalived (10.10.8.213) in the HAProxy. 
Then I created a "HTTP_inet" user account in Active Directory.
Then on my domain controller, in a CMD with administrator permissions, I ran:
setspn -S HTTP/inet.mydomain.local HTTP_inet
setspn -S HTTP/inet HTTP_inet
In both cases the message was: object updated.
Then in my SQUID servers, I executed:
kinit [hidden email]
It asks for the user's password.
Start the ktutil tool
That's where I write:
addent -password -p HTTP/inet.mydomain.local -k 2 -e rc4-hmac
Ask the user password
addent -password -p HTTP/inet -k 2 -e rc4-hmac
Ask the user password
wkt /opt/squid411/etc/PROXY.keytab
quit

list the keys in keytab:
ktutil
read_kt /opt/squid411/etc/PROXY.keytab
   1 1 DEBIAN-PROXY$@MYDOMAIN.LOCAL
   2 1 DEBIAN-PROXY$@MYDOMAIN.LOCAL
   3 1 DEBIAN-PROXY$@MYDOMAIN.LOCAL
   4 1 HTTP/[hidden email]
   5 1 HTTP/[hidden email]
   6 1 HTTP/[hidden email]
   7 1 host/[hidden email]
   8 1 host/[hidden email]
   9 1 host/[hidden email]
  10 1 host/[hidden email]
  11 1 host/[hidden email]
  12 1 host/[hidden email]
  13 2 HTTP/[hidden email]
  14 2 HTTP/[hidden email]

It's this last part I understand the least, maybe the mistake is there. Or somewhere else.
I appreciate any help you can offer me.

Best regards,

Gabriel


_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Problem with HAProxy + Squid 4.11 + Kerberos authentication

L.P.H. van Belle
forgot 1 thing. (sorry)
#
adduser proxyuser winbind_priv
or things might not work.

 


Van: squid-users [mailto:[hidden email]] Namens L.P.H. van Belle
Verzonden: vrijdag 24 juli 2020 10:46
Aan: [hidden email]
Onderwerp: Re: [squid-users] Problem with HAProxy + Squid 4.11 + Kerberos authentication

i would recommend to ..
1) use debian buster,
2) use squid 4.12
3) use samba (winbind).
 
needed  in smb.conf ( only shown whats really needed ), there is more offcourse.

    dedicated keytab file = /etc/krb5.keytab
    kerberos method = secrets and keytab
 
    # renew the kerberos ticket
    winbind refresh tickets = yes
    # Added for freeradius support
    #ntlm auth = mschapv2-and-ntlmv2-only

apt install winbind krb5-user should be sufficient.

samba joins the domain.
/etc/krb5.keytab contains the default part and refreshed the server kerberos passworks/tickes.

And for squid its keytab.

kinit Administrator
export KRB5_KTNAME=FILE:/etc/squid/HTTP-$(hostname -s).keytab
net ads keytab add_update_ads HTTP/$(hostname -f) -U Administrator

# alias name to keytab
net ads keytab ADD HTTP/CNAME.FQDN 

# check keytab file.
klist -ke /etc/squid/HTTP-$(hostname -s).keytab
unset KRB5_KTNAME

# set rights.
chgrp proxy /etc/squid/HTTP-$(hostname -s).keytab
chmod g+r /etc/squid/HTTP-$(hostname -s).keytab

And i use  in squid
auth_param negotiate program /usr/lib/squid/negotiate_wrapper_auth \
    --kerberos /usr/lib/squid/negotiate_kerberos_auth -k /etc/squid/HTTP-hostname.keytab \
    -s [hidden email] -s [hidden email]
    --ntlm /usr/bin/ntlm_auth --helper-protocol=gss-spnego --domain=NTDOM

Point to think about.

server IP's needs A + PTR 
use CNAMEs in the DNS.
and make sure the resolving is setup correctly.

Add a caching DNS to the proxy. ( and let squid use it also )

I had this working (without HAproxy) but with keepalived.

As far i can tel, your problem is in how the hostnames and ip are used. 
but above might give you ideas.

Greetz,

Louis

 


Van: squid-users [mailto:[hidden email]] Namens Service MV
Verzonden: donderdag 23 juli 2020 17:36
Aan: [hidden email]
Onderwerp: [squid-users] Problem with HAProxy + Squid 4.11 + Kerberos authentication

Hi, everybody.
I have a SQUID 4.11 compiled on Debian 9.8 with kerberos integration authenticating and browsing without problems:
cache.log
squid_kerb_auth: User some.user authenticated
access.log
10.10.10.203 TCP_TUNNEL/200 5264 CONNECT update.googleapis.com:443 some.user HIER_DIRECT/MailScanner warning: numerical links are often malicious: MailScanner warning: numerical links are often malicious: MailScanner warning: numerical links are often malicious: MailScanner warning: numerical links are often malicious: 172.217.162.3 -

The problem starts when I try to configure a HAProxy 1.8 load balancer to which by redundancy I configured a virtual IP with the keepalived service. When I point my browser to the DNS A record (balancer.mydomain.local) which in turn points to the keepalived virtual IP, the authentication stops working:
cache.log
no records
access.log
10.10.8.207 TCP_DENIED/407 4142 CONNECT update.googleapis.com:443 - HIER_NONE/- text/

In the client browser a prompt appears requesting authentication.

I find it strange that the IP registered by SQUID is 10.10.8.207, which is the physical IP of my VM, instead of the virtual IP configured in HAProxy, which is the IP 10.10.8.213.

I send you all the configurations that I have made to see if you can help me to find where my configuration error is.

keepalived.conf
  global_defs {
     notification_email {
       [hidden email]
     }
     notification_email_from [hidden email]
     smtp_server smtp. mydomain.local
     smtp_connect_timeout 60
  }

  vrrp_instance VI_1 {
      state MASTER
      interface eth0
      virtual_router_id 101
      priority 101
      advert_int 1
      authentication {
          auth_type PASS
          auth_pass somepass123
      }
      virtual_ipaddress {
          10.10.8.213
      }
  }


haproxy.conf
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
maxconn 4000
ca-base /etc/ssl/certs
crt-base /etc/ssl/private
server=haproxy
ssl-default-bind-ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:RSA+AESGCM:RSA+AES:!aNULL:!MD5:!DSS
ssl-default-bind-options no-sslv3

defaults
balance source
log global
mode http
option httplog
option dontlognull
option http-server-close
option forwardfor except MailScanner warning: numerical links are often malicious: MailScanner warning: numerical links are often malicious: MailScanner warning: numerical links are often malicious: MailScanner warning: numerical links are often malicious: 127.0.0.0/8
timeout connect 5000
timeout client 50000
timeout server 50000

errorfile 400 /etc/haproxy/errors/400.http
errorfile 403 /etc/haproxy/errors/403.http
errorfile 408 /etc/haproxy/errors/408.http
errorfile 500 /etc/haproxy/errors/500.http
errorfile 502 /etc/haproxy/errors/502.http
errorfile 503 /etc/haproxy/errors/503.http
errorfile 504 /etc/haproxy/errors/504.http

### statistics
listen stats
bind MailScanner warning: numerical links are often malicious: MailScanner warning: numerical links are often malicious: MailScanner warning: numerical links are often malicious: MailScanner warning: numerical links are often malicious: 10.10.8.213:1936
mode http
stats enable
stats hide-version
stats realm Haproxy\ Statistics
stats uri /haproxy?stats
stats auth haproxy:somepass123

### balancer
listen squid
bind MailScanner warning: numerical links are often malicious: MailScanner warning: numerical links are often malicious: MailScanner warning: numerical links are often malicious: MailScanner warning: numerical links are often malicious: 10.10.8.213:3128
  mode http
  option httplog
  balance source
  hash-type consistent
  option httpclose
  cookie SERVERID insert indirect nocache
  option forwardfor header X-Client
  server proxy1 MailScanner warning: numerical links are often malicious: MailScanner warning: numerical links are often malicious: MailScanner warning: numerical links are often malicious: MailScanner warning: numerical links are often malicious: 10.10.8.205:3128 check inter 2000 rise 2 fall 5


squid.conf
# minimal configuration for testing
visible_hostname proxy1.mydomain.local
http_port 3128
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 on
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
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


squid -v
Squid Cache: Version 4.11
Service Name: squid

This binary uses OpenSSL 1.0.2u  20 Dec 2019. For legal restrictions on distribution see https://www.openssl.org/source/license.html

configure options:  '--prefix=/opt/squid411' '--includedir=/include' '--mandir=/share/man' '--infodir=/share/info' '--localstatedir=/opt/squid411/var' '--disable-maintainer-mode' '--disable-dependency-tracking' '--disable-silent-rules' '--enable-inline' '--enable-async-io' '--enable-storeio=ufs,aufs,diskd' '--enable-removal-policies=lru,heap' '--enable-delay-pools' '--enable-cache-digests' '--enable-underscores' '--enable-icap-client' '--enable-follow-x-forwarded-for' '--enable-auth' '--enable-digest-auth-helpers' '--enable-negotiate-auth-helpers' '--enable-auth-ntlm' '--enable-arp-acl' '--enable-esi--disable-translation' '--with-logdir=/var/log/squid411' '--with-pidfile=/var/run/squid411.pid' '--with-filedescriptors=65536' '--with-large-files' '--with-default-user=proxy' '--enable-linux-netfilter' '--enable-ltdl-convenience' '--with-openssl' '--enable-ssl' '--enable-ssl-crtd'


env
KRB5_KTNAME=/opt/squid411/etc/PROXY.keytab
KRB5RCACHETYPE=none


/etc/krb5.conf
[libdefaults]
    default_realm = MYDOMAIN.LOCAL
    dns_lookup_kdc = yes
    dns_lookup_realm = yes
    ticket_lifetime = 24h

        default_tgs_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5
        default_tkt_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5
        permitted_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5

[realms]
    MYDOMAIN.LOCAL = {
        kdc = s-dc00.mydomain.local
        kdc = s-dc01.mydomain.local
        kdc = s-dc02.mydomain.local
        admin_server = s-dc00.mydomain.local
    }

[domain_realm]
    .mydomain.local = MYDOMAIN.LOCAL
    mydomain.local = MYDOMAIN.LOCAL


msktutil -c -b "OU=SERVIDORES" -s HTTP/debian-proxy.mydomain.local -k /opt/squid411/etc/PROXY.keytab --computer-name DEBIAN-PROXY --upn HTTP/debian-proxy.mydomain.local --server s-dc00.mydomain.local --verbose --enctypes 28


# permissions for kaytab file
chgrp proxy /opt/squid411/etc/PROXY.keytab
chmod g+r /opt/squid411/etc/PROXY.keytab


klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: [hidden email]

Valid starting       Expires              Service principal
07/23/2020 11:59:45  07/23/2020 21:59:45  krbtgt/[hidden email]
        renew until 07/24/2020 11:59:40


One thing I didn't quite understand is the procedure to authenticate from HAProxy. According to the documentation I read, I did the following:

I created a DNS A record and its PTR in my DNS server pointing to the virtual IP of the keepalived (10.10.8.213) in the HAProxy. 
Then I created a "HTTP_inet" user account in Active Directory.
Then on my domain controller, in a CMD with administrator permissions, I ran:
setspn -S HTTP/inet.mydomain.local HTTP_inet
setspn -S HTTP/inet HTTP_inet
In both cases the message was: object updated.
Then in my SQUID servers, I executed:
kinit [hidden email]
It asks for the user's password.
Start the ktutil tool
That's where I write:
addent -password -p HTTP/inet.mydomain.local -k 2 -e rc4-hmac
Ask the user password
addent -password -p HTTP/inet -k 2 -e rc4-hmac
Ask the user password
wkt /opt/squid411/etc/PROXY.keytab
quit

list the keys in keytab:
ktutil
read_kt /opt/squid411/etc/PROXY.keytab
   1 1 DEBIAN-PROXY$@MYDOMAIN.LOCAL
   2 1 DEBIAN-PROXY$@MYDOMAIN.LOCAL
   3 1 DEBIAN-PROXY$@MYDOMAIN.LOCAL
   4 1 HTTP/[hidden email]
   5 1 HTTP/[hidden email]
   6 1 HTTP/[hidden email]
   7 1 host/[hidden email]
   8 1 host/[hidden email]
   9 1 host/[hidden email]
  10 1 host/[hidden email]
  11 1 host/[hidden email]
  12 1 host/[hidden email]
  13 2 HTTP/[hidden email]
  14 2 HTTP/[hidden email]

It's this last part I understand the least, maybe the mistake is there. Or somewhere else.
I appreciate any help you can offer me.

Best regards,

Gabriel


_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Problem with HAProxy + Squid 4.11 + Kerberos authentication

Rafael Akchurin
In reply to this post by Brett Lymn-2
Hello Klaus, Brett, all list members,

This is the scheme with haproxy and Squid we use all the time in our test lab for Web Safety - we need to constantly add/remove test nodes to the cluster without breaking/changing anything in Kerberos settings for the constantly running client pool - https://docs.diladele.com/administrator_guide_stable/active_directory_extra/redundancy/haproxy_proxy_protocol.html

And yes we do *not* use computer account, we use *user* account instead.
See the reasoning  in the tutorial.

Best regards,
Rafael Akchurin
Diladele B.V.

 

-----Original Message-----
From: squid-users <[hidden email]> On Behalf Of Brett Lymn
Sent: Friday, July 24, 2020 2:23 AM
To: Klaus Brandl <[hidden email]>
Cc: [hidden email]
Subject: Re: [squid-users] Problem with HAProxy + Squid 4.11 + Kerberos authentication

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.

--
Brett Lymn
This email has been sent on behalf of one of the following companies within the BAE Systems Australia group of companies:

BAE Systems Australia Limited - Australian Company Number 008 423 005 BAE Systems Australia Defence Pty Limited - Australian Company Number 006 870 846 ASC Shipbuilding Pty Limited - Australian Company Number 051 899 864

BAE Systems Australia's registered office is Evans Building, Taranaki Road, Edinburgh Parks, Edindurgh, South Australia, 5111.
ASC Shipbuilding's registered office is Level 2, 80 Flinders Street, Adelaide, South Australia, 5000.
If the identity of the sending company is not clear from the content of this email, please contact the sender.

This email and any attachments may contain confidential and legally privileged information. If you are not the intended recipient, do not copy or disclose its content, but please reply to this email immediately and highlight the error to the sender and then immediately delete the message.

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Problem with HAProxy + Squid 4.11 + Kerberos authentication

Rafael Akchurin
In reply to this post by Klaus Brandl
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 <[hidden email]> On Behalf Of Klaus Brandl
Sent: Friday, July 24, 2020 10:45 AM
To: [hidden email]
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
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Problem with HAProxy + Squid 4.11 + Kerberos authentication

L.P.H. van Belle
In reply to this post by Rafael Akchurin
Hai Rafael,

First, thank you for maintaining diladele, each time i read them,
i learned something :-) As usual, your manuals look great.

I have a few suggestion if i may point these out, just small update for the site.

https://docs.diladele.com/administrator_guide_stable/active_directory/kerberos/keytab.html
This part, The krb5.conf should be updated it with.

; for Windows 2008+ with AES support ( you might want to remove rc4 and des, its there for compatibility)
    default_tgs_enctypes = aes128-cts-hmac-sha1-96 aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5
    default_tkt_enctypes = aes128-cts-hmac-sha1-96 aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5
    permitted_enctypes = aes128-cts-hmac-sha1-96 aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5


https://docs.diladele.com/administrator_guide_stable/active_directory/create_user/index.html
/quote:
Some tutorials describing integration of Squid with Active Directory rely on creating special computer account in AD for the same goal. Unfortunately it ties the proxy machine to Active Directory and prevents us from making and restoring VM snapshots because the restored snapshot loses the AD join state and needs to be rejoined manually.
/quote.

Well, all i can say here is, this works fine for me, but i understand where its coming from.
As your pointing out, yes, i did use a "user" account also in the past.
But if samba/winbind is setup correcty with its hostName, and you use CNAMES for the proxy it's serviceName,
after a backup/restore of a VM and samba/winbind starts, winbind handles the "computername" keytab and its password.
Squid has its own keytab file and CNAME and is untouched.

Resulting in, you can restore a VM. I do this on XenServers, i suggest, give it a try.
But note, i dont have HAProxy running (yet), so i cant say anyting about that part,
The logical parts should be the same (hostname A - PTR and CNAMES for serices)

The COMPUTER needs A and PTR (this is the real hostname)
Now you can setup any CNAME SPN for the proxy it's "ServiceName"
You can use or the computer account or a separated account for the Squid CNAME-ed SPN's.
Als long these are somewhere to findable in AD.

You might want to test this, this setup removed the need of ktpass in windows,
which was always giving problems at my side.

And last, if winbind is use and you want to add a automounted homedir with NFS or CIFS.
Then half of the work is already done.
It basicly only needs : nfs-common nfs4-acl-tools
And :
net ads keytab add_update_ads nfs/$(hostname -f) -U Administrator
And/or
net ads keytab add_update_ads cifs/$(hostname -f) -U Administrator

In the Haproxy setup, well, thats next on my list,
i saw something i liked and dont have it running yet.  
Learning a lot here. :-)

Main difference between your setups, i dont have any windows servers.
I running fully on Samba AD-DC's and member servers and my client PC's are windows 10.

I hope I could give you someone ideas here and people can use them.
If you have questions, just ask.


Greetz,

Louis



> -----Oorspronkelijk bericht-----
> Van: squid-users
> [mailto:[hidden email]] Namens
> Rafael Akchurin
> Verzonden: vrijdag 24 juli 2020 11:39
> Aan: Brett Lymn; Klaus Brandl
> CC: [hidden email]
> Onderwerp: Re: [squid-users] Problem with HAProxy + Squid
> 4.11 + Kerberos authentication
>
> Hello Klaus, Brett, all list members,
>
> This is the scheme with haproxy and Squid we use all the time
> in our test lab for Web Safety - we need to constantly
> add/remove test nodes to the cluster without
> breaking/changing anything in Kerberos settings for the
> constantly running client pool -
> https://docs.diladele.com/administrator_guide_stable/active_di
> rectory_extra/redundancy/haproxy_proxy_protocol.html
>
> And yes we do *not* use computer account, we use *user*
> account instead.
> See the reasoning  in the tutorial.
>
> Best regards,
> Rafael Akchurin
> Diladele B.V.
>
>  
>
> -----Original Message-----
> From: squid-users <[hidden email]>
> On Behalf Of Brett Lymn
> Sent: Friday, July 24, 2020 2:23 AM
> To: Klaus Brandl <[hidden email]>
> Cc: [hidden email]
> Subject: Re: [squid-users] Problem with HAProxy + Squid 4.11
> + Kerberos authentication
>
> 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.
>
> --
> Brett Lymn
> This email has been sent on behalf of one of the following
> companies within the BAE Systems Australia group of companies:
>
> BAE Systems Australia Limited - Australian Company Number 008
> 423 005 BAE Systems Australia Defence Pty Limited -
> Australian Company Number 006 870 846 ASC Shipbuilding Pty
> Limited - Australian Company Number 051 899 864
>
> BAE Systems Australia's registered office is Evans Building,
> Taranaki Road, Edinburgh Parks, Edindurgh, South Australia, 5111.
> ASC Shipbuilding's registered office is Level 2, 80 Flinders
> Street, Adelaide, South Australia, 5000.
> If the identity of the sending company is not clear from the
> content of this email, please contact the sender.
>
> This email and any attachments may contain confidential and
> legally privileged information. If you are not the intended
> recipient, do not copy or disclose its content, but please
> reply to this email immediately and highlight the error to
> the sender and then immediately delete the message.
>
> _______________________________________________
> squid-users mailing list
> [hidden email]
> http://lists.squid-cache.org/listinfo/squid-users
> _______________________________________________
> squid-users mailing list
> [hidden email]
> http://lists.squid-cache.org/listinfo/squid-users
>

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Problem with HAProxy + Squid 4.11 + Kerberos authentication

neok
In reply to this post by Brett Lymn-2
Thanks, Brett, for the answer. I did exactly the same thing and it's working for me now.
I only have to decrypt how to see the client's IP in SQUID's logs. I will follow your instructions to try to achieve it.

Best regards,

Gabriel


El jue., 23 de jul. de 2020 a la(s) 21:23, Brett Lymn ([hidden email]) escribió:
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.

--
Brett Lymn
This email has been sent on behalf of one of the following companies within the BAE Systems Australia group of companies:

BAE Systems Australia Limited - Australian Company Number 008 423 005
BAE Systems Australia Defence Pty Limited - Australian Company Number 006 870 846
ASC Shipbuilding Pty Limited - Australian Company Number 051 899 864

BAE Systems Australia's registered office is Evans Building, Taranaki Road, Edinburgh Parks, Edindurgh, South Australia, 5111.
ASC Shipbuilding's registered office is Level 2, 80 Flinders Street, Adelaide, South Australia, 5000.
If the identity of the sending company is not clear from the content of this email, please contact the sender.

This email and any attachments may contain confidential and legally privileged information. If you are not the intended recipient, do not copy or disclose its content, but please reply to this email immediately and highlight the error to the sender and then immediately delete the message.

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Problem with HAProxy + Squid 4.11 + Kerberos authentication

neok
In reply to this post by Amos Jeffries
Thanks Amos, Kerberos is really hard to learn for a rookie like me, but you explained it in an excellent and concise way.
In my case, the SQUID servers are joined to the domain with their respective SPN and UPN that I mentioned in the msktutil command.
And in the case of the Load Balancer HAProxy I used a user account and I set that the password does not expire. I know this may not be the safest way to do it, but I couldn't find a way to do it with a computer account. I guess I should join the HAProxy to the domain as well.
The detail, as you mentioned, is that the DNS A record (eg inet.mydomain.local) is to match exactly the SPN for that user account, which at this point is a service account.

Thanks again

Gabriel

El vie., 24 de jul. de 2020 a la(s) 00:10, Amos Jeffries ([hidden email]) escribió:
On 24/07/20 5:09 am, Service MV wrote:
> Hi Klaus,
> I think something similar. But I understand that you can use the
> Kerberos delegation in AD. That's partly why I'm not convinced by the
> documentation I read, which tells me to create a user account in Active
> Directory. And I don't understand what a user account has to do here.
> Maybe the documentation is wrong and actually refers to a computer
> account, and the operation of adding a Service Principal Name should be
> done to the computer object. I don't know. But I'm going to try to do it
> and see what I can achieve.
>

Kerberos authentication in HTTP uses the Negotiate scheme. The model for
that scheme is that it authenticates the exact TCP connection over which
the credentials are transmitted.

So for it to work *through* a proxy (eg HAProxy) that proxy must ensure
the *two* TCP connections it is handling (from-client and to-Squid) are
pinned together with all HTTP multiplexing features disabled _and_ the
Proxy-Auth* headers are not touched or used along the way.

 => If either of those conditions is broken the auth will not work and
users will definitely get the behaviour you are seeing. That behaviour
may also occur anyway if later stages are broken - this is just the
first and most non-obvious problem for beginners.


[ below is simplified a bit/lot to ensure you have the basic
understanding. There is a steep learning curve for Kerberos tools and
one needs basics before troubleshooting exposes the gory details ]

The HTTP agent which is doing the Kerberos auth validation (eg Squid)
must be configured with an account that can perform authentication tasks
with the central domain server.
 This can be either User or Machine account as you know. The important
difference is their policy on passwords. User accounts need password
rotation, machines are effectively permanent. Since keytab used by Squid
has to be re-generated every time the account password changes User
accounts are naturally far more complex to administrate for reliable auth.

 => So ... your choice and YMMV. But we recommend a machine account
unless you have reason to go the more complex way.


At the other end the client software needs a keytab with a "Principal"
name telling it what to request from the central domain server when it
needs a token that Squid can validate.

 => The principal name has to match up with the account details used by
the proxy which is checking the auth credentials. This is why the middle
proxy (eg HAProxy) cannot touch the authentication on its way to Squid.

 => The principal name is also case-sensitive and and must survive
*exact* string comparisons despite DNS resolve being involved [ because
reasons :( ].  So be sure to use full FQDN rather than host name
abbreviations.



> I'll be back.
>
> El jue., 23 de jul. de 2020 a la(s) 13:16, Klaus Brandl escribió:
>
>     Hi Gabriel,
>
>     same problem here on our HA systems.
>     I think, this is caused by kerberos overall, the tickets are always
>     bound to
>     the hosts realname and address, look at "klist" on your client, and
>     only
>     exactly this name could be used as proxy entry.


Indeed. Use of wrong names (eg not using the full FQDN), wrong case, or
the hostnames not being DNS resolvable are common causes of Kerberos not
working.


Amos

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Problem with HAProxy + Squid 4.11 + Kerberos authentication

Markus Moeller
In reply to this post by L.P.H. van Belle
Hi
 
 
Maybe some general comments about LB, CNAMEs and Squid Kerberos will help.  The kerberos client will try to request a ticket based on the used hostname. e.g. if you configure in your browser the proxy name as  ha-proxy.slb.example.com then the client will look for a serviceprincipal of HTTP/ha-proxy.slb.example.com. If this is a Cname then you may have browser dependencies e.g.
 
  ha-proxy.slb.example.com CNAME HA-server1.real.example.com
 
Some browsers will use HTTP/ha-proxy.slb.example.com  and some will use HTTP/HA-server1.real.example.com 
 
Now if your squid server name is squid1.real.example.com you will have probably only HTTP/squid1.real.example.com  in your keytab. 
 
 
There are now 2 Options:
 
1 ) Create one entry in AD for all squid servers  i.e. the AD entry will have at least number of servers + 2  service principals associated to it, extract the key to a keytab and use the option –s GSS_C_NO_NAME with the negotiate_kerberos_auth helper
     .e.g HTTP/squid1.real.example.com , HTTP/squid2.real.example.com , HTTP/HA-server1.real.example.com  ,  HTTP/ha-proxy.slb.example.com 
2) Create separate entries in AD for each squid server, the LB and the CNAMEs and then merge the keys into one keytab to be used on all squid servers.
 
Kind Regards
Markus
 
 
 
"L.P.H. van Belle" <[hidden email]> wrote in message news:[hidden email]...
forgot 1 thing. (sorry)
#
adduser proxyuser winbind_priv
or things might not work.

 


Van: squid-users [mailto:[hidden email]] Namens L.P.H. van Belle
Verzonden: vrijdag 24 juli 2020 10:46
Aan: [hidden email]
Onderwerp: Re: [squid-users] Problem with HAProxy + Squid 4.11 + Kerberos authentication

i would recommend to ..
1) use debian buster,
2) use squid 4.12
3) use samba (winbind).
 
needed  in smb.conf ( only shown whats really needed ), there is more offcourse.

    dedicated keytab file = /etc/krb5.keytab
    kerberos method = secrets and keytab
 
    # renew the kerberos ticket
    winbind refresh tickets = yes
    # Added for freeradius support
    #ntlm auth = mschapv2-and-ntlmv2-only

apt install winbind krb5-user should be sufficient.

samba joins the domain.
/etc/krb5.keytab contains the default part and refreshed the server kerberos passworks/tickes.

And for squid its keytab.

kinit Administrator
export KRB5_KTNAME=FILE:/etc/squid/HTTP-$(hostname -s).keytab
net ads keytab add_update_ads HTTP/$(hostname -f) -U Administrator

# alias name to keytab
net ads keytab ADD HTTP/CNAME.FQDN

# check keytab file.
klist -ke /etc/squid/HTTP-$(hostname -s).keytab
unset KRB5_KTNAME

# set rights.
chgrp proxy /etc/squid/HTTP-$(hostname -s).keytab
chmod g+r /etc/squid/HTTP-$(hostname -s).keytab

And i use  in squid
auth_param negotiate program /usr/lib/squid/negotiate_wrapper_auth \
    --kerberos /usr/lib/squid/negotiate_kerberos_auth -k /etc/squid/HTTP-hostname.keytab \
    -s HTTP/hostname.fqdn@REALM -s HTTP/CNAME.FQDN@REALM
    --ntlm /usr/bin/ntlm_auth --helper-protocol=gss-spnego --domain=NTDOM

Point to think about.

server IP's needs A + PTR
use CNAMEs in the DNS.
and make sure the resolving is setup correctly.

Add a caching DNS to the proxy. ( and let squid use it also )

I had this working (without HAproxy) but with keepalived.

As far i can tel, your problem is in how the hostnames and ip are used.
but above might give you ideas.

Greetz,

Louis

 


Van: squid-users [mailto:[hidden email]] Namens Service MV
Verzonden: donderdag 23 juli 2020 17:36
Aan: [hidden email]
Onderwerp: [squid-users] Problem with HAProxy + Squid 4.11 + Kerberos authentication

Hi, everybody.
I have a SQUID 4.11 compiled on Debian 9.8 with kerberos integration authenticating and browsing without problems:
cache.log
squid_kerb_auth: User some.user authenticated
access.log
10.10.10.203 TCP_TUNNEL/200 5264 CONNECT update.googleapis.com:443 some.user HIER_DIRECT/MailScanner warning: numerical links are often malicious: MailScanner warning: numerical links are often malicious: MailScanner warning: numerical links are often malicious: MailScanner warning: numerical links are often malicious: 172.217.162.3 -

The problem starts when I try to configure a HAProxy 1.8 load balancer to which by redundancy I configured a virtual IP with the keepalived service. When I point my browser to the DNS A record (balancer.mydomain.local) which in turn points to the keepalived virtual IP, the authentication stops working:
cache.log
no records
access.log
10.10.8.207 TCP_DENIED/407 4142 CONNECT update.googleapis.com:443 - HIER_NONE/- text/
 
In the client browser a prompt appears requesting authentication.

I find it strange that the IP registered by SQUID is 10.10.8.207, which is the physical IP of my VM, instead of the virtual IP configured in HAProxy, which is the IP 10.10.8.213.

I send you all the configurations that I have made to see if you can help me to find where my configuration error is.

keepalived.conf
  global_defs {
     notification_email {
       [hidden email]
     }
     notification_email_from [hidden email]
     smtp_server smtp. mydomain.local
     smtp_connect_timeout 60
  }

  vrrp_instance VI_1 {
      state MASTER
      interface eth0
      virtual_router_id 101
      priority 101
      advert_int 1
      authentication {
          auth_type PASS
          auth_pass somepass123
      }
      virtual_ipaddress {
          10.10.8.213
      }
  }

 
haproxy.conf
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
maxconn 4000
ca-base /etc/ssl/certs
crt-base /etc/ssl/private
server=haproxy
ssl-default-bind-ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:RSA+AESGCM:RSA+AES:!aNULL:!MD5:!DSS
ssl-default-bind-options no-sslv3

defaults
balance source
log global
mode http
option httplog
option dontlognull
option http-server-close
option forwardfor except MailScanner warning: numerical links are often malicious: MailScanner warning: numerical links are often malicious: MailScanner warning: numerical links are often malicious: MailScanner warning: numerical links are often malicious: 127.0.0.0/8
timeout connect 5000
timeout client 50000
timeout server 50000

errorfile 400 /etc/haproxy/errors/400.http
errorfile 403 /etc/haproxy/errors/403.http
errorfile 408 /etc/haproxy/errors/408.http
errorfile 500 /etc/haproxy/errors/500.http
errorfile 502 /etc/haproxy/errors/502.http
errorfile 503 /etc/haproxy/errors/503.http
errorfile 504 /etc/haproxy/errors/504.http

### statistics
listen stats
bind MailScanner warning: numerical links are often malicious: MailScanner warning: numerical links are often malicious: MailScanner warning: numerical links are often malicious: MailScanner warning: numerical links are often malicious: 10.10.8.213:1936
mode http
stats enable
stats hide-version
stats realm Haproxy\ Statistics
stats uri /haproxy?stats
stats auth haproxy:somepass123

### balancer
listen squid
bind MailScanner warning: numerical links are often malicious: MailScanner warning: numerical links are often malicious: MailScanner warning: numerical links are often malicious: MailScanner warning: numerical links are often malicious: 10.10.8.213:3128
  mode http
  option httplog
  balance source
  hash-type consistent
  option httpclose
  cookie SERVERID insert indirect nocache
  option forwardfor header X-Client
  server proxy1 MailScanner warning: numerical links are often malicious: MailScanner warning: numerical links are often malicious: MailScanner warning: numerical links are often malicious: MailScanner warning: numerical links are often malicious: 10.10.8.205:3128 check inter 2000 rise 2 fall 5
 
 
squid.conf
# minimal configuration for testing
visible_hostname proxy1.mydomain.local
http_port 3128
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 on
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
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
 
 
squid -v
Squid Cache: Version 4.11
Service Name: squid

This binary uses OpenSSL 1.0.2u  20 Dec 2019. For legal restrictions on distribution see https://www.openssl.org/source/license.html

configure options:  '--prefix=/opt/squid411' '--includedir=/include' '--mandir=/share/man' '--infodir=/share/info' '--localstatedir=/opt/squid411/var' '--disable-maintainer-mode' '--disable-dependency-tracking' '--disable-silent-rules' '--enable-inline' '--enable-async-io' '--enable-storeio=ufs,aufs,diskd' '--enable-removal-policies=lru,heap' '--enable-delay-pools' '--enable-cache-digests' '--enable-underscores' '--enable-icap-client' '--enable-follow-x-forwarded-for' '--enable-auth' '--enable-digest-auth-helpers' '--enable-negotiate-auth-helpers' '--enable-auth-ntlm' '--enable-arp-acl' '--enable-esi--disable-translation' '--with-logdir=/var/log/squid411' '--with-pidfile=/var/run/squid411.pid' '--with-filedescriptors=65536' '--with-large-files' '--with-default-user=proxy' '--enable-linux-netfilter' '--enable-ltdl-convenience' '--with-openssl' '--enable-ssl' '--enable-ssl-crtd'
 
 
env
KRB5_KTNAME=/opt/squid411/etc/PROXY.keytab
KRB5RCACHETYPE=none
 
 
/etc/krb5.conf
[libdefaults]
    default_realm = MYDOMAIN.LOCAL
    dns_lookup_kdc = yes
    dns_lookup_realm = yes
    ticket_lifetime = 24h

        default_tgs_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5
        default_tkt_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5
        permitted_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5

[realms]
    MYDOMAIN.LOCAL = {
        kdc = s-dc00.mydomain.local
        kdc = s-dc01.mydomain.local
        kdc = s-dc02.mydomain.local
        admin_server = s-dc00.mydomain.local
    }

[domain_realm]
    .mydomain.local = MYDOMAIN.LOCAL
    mydomain.local = MYDOMAIN.LOCAL
 
 
msktutil -c -b "OU=SERVIDORES" -s HTTP/debian-proxy.mydomain.local -k /opt/squid411/etc/PROXY.keytab --computer-name DEBIAN-PROXY --upn HTTP/debian-proxy.mydomain.local --server s-dc00.mydomain.local --verbose --enctypes 28
 
 
# permissions for kaytab file
chgrp proxy /opt/squid411/etc/PROXY.keytab
chmod g+r /opt/squid411/etc/PROXY.keytab
 
 
klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: [hidden email]

Valid starting       Expires              Service principal
07/23/2020 11:59:45  07/23/2020 21:59:45  krbtgt/[hidden email]
        renew until 07/24/2020 11:59:40
 
 
One thing I didn't quite understand is the procedure to authenticate from HAProxy. According to the documentation I read, I did the following:

I created a DNS A record and its PTR in my DNS server pointing to the virtual IP of the keepalived (10.10.8.213) in the HAProxy.
Then I created a "HTTP_inet" user account in Active Directory.
Then on my domain controller, in a CMD with administrator permissions, I ran:
setspn -S HTTP/inet.mydomain.local HTTP_inet
setspn -S HTTP/inet HTTP_inet
In both cases the message was: object updated.
Then in my SQUID servers, I executed:
kinit [hidden email]
It asks for the user's password.
Start the ktutil tool
That's where I write:
addent -password -p HTTP/inet.mydomain.local -k 2 -e rc4-hmac
Ask the user password
addent -password -p HTTP/inet -k 2 -e rc4-hmac
Ask the user password
wkt /opt/squid411/etc/PROXY.keytab
quit

list the keys in keytab:
ktutil
read_kt /opt/squid411/etc/PROXY.keytab
   1 1 DEBIAN-PROXY$@MYDOMAIN.LOCAL
   2 1 DEBIAN-PROXY$@MYDOMAIN.LOCAL
   3 1 DEBIAN-PROXY$@MYDOMAIN.LOCAL
   4 1 HTTP/[hidden email]
   5 1 HTTP/[hidden email]
   6 1 HTTP/[hidden email]
   7 1 host/[hidden email]
   8 1 host/[hidden email]
   9 1 host/[hidden email]
  10 1 host/[hidden email]
  11 1 host/[hidden email]
  12 1 host/[hidden email]
  13 2 HTTP/[hidden email]
  14 2 HTTP/[hidden email]

It's this last part I understand the least, maybe the mistake is there. Or somewhere else.
I appreciate any help you can offer me.

Best regards,

Gabriel
 


_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Problem with HAProxy + Squid 4.11 + Kerberos authentication

Brett Lymn-2
In reply to this post by Klaus Brandl
On Fri, Jul 24, 2020 at 10:44:34AM +0200, Klaus Brandl wrote:
>
> 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.
>

No, you don't have a single point of failure, this is why I mentioned
using ktutil (well, I said ktadmin, my bad).  You merge the keytab for
the machine with the keytab for the HA user.  This way the clients are
able to both auth to the HA and to the the underlying machine.  It is
what we do, it works fine.

--
Brett Lymn
This email has been sent on behalf of one of the following companies within the BAE Systems Australia group of companies:

BAE Systems Australia Limited - Australian Company Number 008 423 005
BAE Systems Australia Defence Pty Limited - Australian Company Number 006 870 846
ASC Shipbuilding Pty Limited - Australian Company Number 051 899 864

BAE Systems Australia's registered office is Evans Building, Taranaki Road, Edinburgh Parks, Edindurgh, South Australia, 5111.
ASC Shipbuilding's registered office is Level 2, 80 Flinders Street, Adelaide, South Australia, 5000.
If the identity of the sending company is not clear from the content of this email, please contact the sender.

This email and any attachments may contain confidential and legally privileged information. If you are not the intended recipient, do not copy or disclose its content, but please reply to this email immediately and highlight the error to the sender and then immediately delete the message.

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Problem with HAProxy + Squid 4.11 + Kerberos authentication

neok
In reply to this post by Rafael Akchurin
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/[hidden email]
   5 1 HTTP/[hidden email]
   6 1 HTTP/[hidden email]
   7 1 host/[hidden email]
   8 1 host/[hidden email]
   9 1 host/[hidden email]
  10 1 host/[hidden email]
  11 1 host/[hidden email]
  12 1 host/[hidden email]
  13 2 HTTP/[hidden email]
  14 2 HTTP/[hidden email]

global_defs {
    notification_email {
      [hidden email]
    }
    notification_email_from [hidden email]
    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 ([hidden email]) 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 <[hidden email]> On Behalf Of Klaus Brandl
Sent: Friday, July 24, 2020 10:45 AM
To: [hidden email]
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
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users