On 13/06/25 20:08, wong237ma wrote:
Hi,
I had successfully setup squid-openssl (6.10) in Ubuntu 24.04.02 LTS,
staging and production. I refer to this squid wiki: https://wiki.squid-
cache.org/ConfigExamples/Authenticate/WindowsActiveDirectory. I had
setup Squid-cache authenticate against Activi Directory via kerberos.
For proxy user access to staging, windows users (joined AD) no issue on
authentication. I test users authenticate seemlessly without any prompt.
Our office user around 600. when I turn on production proxy. At morning
9am, when user number hit around 100, no issue raise. when user number
hit around 250++, windows users, the browser start to prompt user login,
FTR; the login prompt is not coming from Squid. The client Browser
decides where to get credentials from - the popup is one source, current
machine login another, there may be sources as well.
Most often in situations like this, the ActiveDirectory or network
cannot cope with the number of concurrent credential verification Squid
is needing to perform.
Alternatively it may just be the clients Browser(s) deciding that login
has failed and giving up before authentication completes - when the high
load makes verification slow.
even domain credential are correct, but seem not work, after that user
cannot surf any website.
There will be a timeouts controlling this.
Since you are SSL-Bump'ing traffic - whatever result the initial CONNECT
request credentials were given when the TLS began will be used until
that TLS connection closes.
Secondly the auth helper "negative-ttl=900" (from config below) value
will make Squid only check for different results on new connections
started 900+ seconds after the first one was rejected.
How to troubleshoot this issue?
I use squidclient to monitor external_acl, negotiateauthenticator,
ntlmauthenticator, basicauthenticator, so far no requests timedout.
I also monitor cache.log with filtering "FATAL:|WARNING:|
squidaio_queue_request:|SECURITY ALERT:" didn't find any specifc error.
You are unlikely to find anything in the Squid logs. Unless one of the
auth helpers is having issues with its access to your ActiveDirectory
server.
Can help to identify, wonder user still got domain login prompt from,
e.g. internet browser, like chrome, edge or firefox, outlook and
microsoft teams, etc.
Appciate any help.
Thanks.
attach my squid.conf:
=======================================
## negotiate kerberos and ntlm authentication
auth_param negotiate program /usr/lib/squid/negotiate_wrapper_auth -d --
ntlm /usr/bin/ntlm_auth --diagnostics --helper-protocol=squid-2.5-
ntlmssp --domain=MYCOMPANY --kerberos /usr/lib/squid/
negotiate_kerberos_auth -d -s GSS_C_NO_NAME
auth_param negotiate children 3000 startup=500 idle=200
auth_param negotiate keep_alive on
authenticate_ttl 15 minutes
## pure ntlm authentication
auth_param ntlm program /usr/bin/ntlm_auth --diagnostics --helper-
protocol=squid-2.5-ntlmssp --domain=MYCOMPANY
auth_param ntlm children 500 startup=50 idle=10
auth_param ntlm keep_alive off
Do you still actually **need** NTLM ?
It has been deprecated for 19 years already, and Windows software has
progressively been removing the ability to use it.
You may be able to get some metrics out of ActiveDirectory, or the
server it runs on to measure how many logins are NTLM vs Kerberos.
### provide basic authentication via ldap for clients not authenticated
via kerberos/ntlm
auth_param basic program /usr/lib/squid/basic_ldap_auth -R -b
"dc=mycompany,dc=com" -D squidproxyu...@mycompany.com -W /etc/squid/
ldappass.txt -f sAMAccountName=%s -h mycompanydc.mycompany.com
auth_param basic children 500 startup=50 idle=10
auth_param basic realm Internet Proxy
auth_param basic credentialsttl 1 minute
#external_acl_type hebadgroup %LOGIN /usr/lib/squid/ext_wbinfo_group_acl
external_acl_type hebadgroup children-max=1000 children-startup=50
children-idle=10 ttl=900 negative_ttl=900 %LOGIN /usr/lib/squid/
ext_wbinfo_group_acl
The Kerberos auth helper bundled with Squid delivers "group="
annotations back to Squid that can be quickly checked instead of using
extra helper lookups.
Find the SSID in ActiveDirectory for the group (eg "sq_whatsapp") and
replace your:
acl grpwhatsapp external ...
with this (where "SSID" is the string from ActiveDirectory):
acl grpwhatsapp note group SSID
same for the other groups this helper is used for.
http_port 3128 ssl-bump generate-host-certificates=on
dynamic_cert_mem_cache_size=20MB tls-cert=/etc/squid/cert/squid.crt tls-
key=/etc/squid/cert/ca.key
sslcrtd_program /usr/lib/squid/security_file_certgen -s /var/lib/squid/
ssl_db -M 20MB
sslcrtd_children 50
acl localnet src 0.0.0.1-0.255.255.255 # RFC 1122 "this" network (LAN)
acl localnet src 10.0.0.0/8 # RFC 1918 local private network
(LAN)
acl localnet src 100.64.0.0/10 # RFC 6598 shared address space
(CGN)
acl localnet src 169.254.0.0/16 # RFC 3927 link-local (directly
plugged) machines
acl localnet src 172.16.0.0/12 # RFC 1918 local private network
(LAN)
acl localnet src 192.168.0.0/16 # RFC 1918 local private network
(LAN)
acl localnet src fc00::/7 # RFC 4193 local private network
range
acl localnet src fe80::/10 # RFC 4291 link-local (directly
plugged) machines
acl SSL_ports port 443
acl Safe_ports port 80 # http
acl Safe_ports port 21 # ftp
acl Safe_ports port 443 # https
acl Safe_ports port 70 # gopher
acl Safe_ports port 210 # wais
acl Safe_ports port 1025-65535 # unregistered ports
acl Safe_ports port 280 # http-mgmt
acl Safe_ports port 488 # gss-http
acl Safe_ports port 591 # filemaker
acl Safe_ports port 777 # multiling http
acl direct_access dstdomain openshiftapps.com
cache deny direct_access
Hmm. calling that ACL "direct_access" implies that whoever designed it
thinks the "cache" directive has something to do with accessing things.
It does not.
The above two config lines prevent Squid from _storing_ any traffic when
the domain is exactly the string "openshiftapps.com" (emphasis on the
exact part, "www.openshiftapps.com" and similar will **not** match that
ACL definition). So nothing from there should be able to produce HIT or
REFRESH type responses.
acl urlwhatsapp dstdomain .whatsapp.com
acl grpwhatsapp external adgroup sq_whatsapp
acl grpgithub external adgroup SSLVPN-GitHub-CoPilot
# Enable Proxy Authentication
acl aduser proxy_auth REQUIRED
# Domains for SSL Bump
acl url_sslbump dstdomain .github.com
# Define SSL Bump steps
acl step1 at_step SslBump1
acl step2 at_step SslBump2
acl step3 at_step SslBump3
# SSL Bump rules for specific traffic
ssl_bump peek step1 all
ssl_bump bump step2 url_sslbump
ssl_bump splice all # Splice (do not bump) all other
traffic
sslproxy_cert_error allow url_sslbump
#http_access deny !Safe_ports
#http_access deny CONNECT !SSL_ports
http_access allow localhost manager
http_access deny manager
http_access allow localhost
http_access deny to_localhost
http_access deny to_linklocal
include /etc/squid/conf.d/*.conf
# Access control for GitHub Copilot Group
include /etc/squid/github.conf
FYI, notice that Squid is automatically including all the config files
in the directory /etc/squid/conf.d/
You should only need to drop the file github.conf into that directory
and not include it here.
http_access allow urlwhatsapp grpwhatsapp
http_access deny urlwhatsapp
http_access allow aduser
> http_access deny all
>
Login should happen before any of the ACLs that check group memberships
or other auth related things.
When done that way it should look something like this:
# require credentials to both exist and be valid
acl login proxy_auth REQUIRED
http_access deny !login
# ACLs that use login credentials or login related details
http_access allow group_A somewhere
http_access deny group_B
...
# maybe allow any LAN clients not denied above.
http_access allow localnet
http_access deny all
HTH
Amos
_______________________________________________
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users
