[squid-users] User got domain login dialog box prompt, when number of user more than 250++

Amos Jeffries squid3 at treenet.co.nz
Fri Jun 13 10:09:35 UTC 2025


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 squidproxyuser at 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



More information about the squid-users mailing list