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