> On Mon, 14 Nov 2011 14:50:02 +0000, John Sayce wrote: >> I have squid configured and working fine with ntlm authentication, >> however about once a week access to the throughput will slow and I >> can >> be presented with access denied messages. Restarting squid instantly >> fixes the problem. My configuration is relatively simple as bellow. >> I >> don't have a large user base. There's only 60 users and the problem >> is >> instantly gone upon restarting squid which suggests to me that it's >> not simply be a problem of load as the log would suggest. I wondered >> if it was a single computer or application causing the issue but I'm >> not sure how to find out. >> >> http_port 8080 >> >> auth_param ntlm program c:/squid/libexec/mswin_ntlm_auth.exe >> auth_param ntlm children 30 >> external_acl_type win_domain_group children=30 ttl=120 %LOGIN >> c:/squid/libexec/mswin_check_lm_group.exe -G >> >> acl all src 0.0.0.0/0.0.0.0 >> acl nocache dstdomain "C:\squid\etc\nocache_domains.acl" >> acl unauthenticatednet src "C:\squid\etc\unrestrictedaddresses.acl" >> acl blocked src "C:\squid\etc\restrictedaddresses.acl" >> acl inetallowgroup external win_domain_group InternetAllow >> acl inetrestrictgroup external win_domain_group InternetRestricted >> acl localhost src 127.0.0.1/255.255.255.255 >> acl localnet proxy_auth REQUIRED src 192.168.0.0/255.255.255.0 > > The above ACL definition has never been valid. > > Perhapse you wanted: > acl localnet src 192.168.0.0/24 > acl login proxy_auth REQUIRED > > http_access deny !localnet > http_access deny !login > > The "deny !localnet" will prevent non-LAN users from logging in. If you > can do that great. It will prevent external machines flooding your proxy > with malicious login load. > > The "deny !login" is to do the user login quickly and reject early if > they fail that. From your logs below I see 3x lookups being done, one > for each group check. All of which are failing due to invalid domain > name on the user credentials. Doing this "deny !login" will drop the > speed loss on the failure cases by more than 60%. > > I've implemented this. I'd strugled to find documentation on the formating and syntax for ntlm authentication. Thanks. >> acl denied_domains dstdomain "C:\squid\etc\denied_domains.acl" >> acl allowed_domains dstdomain "C:\squid\etc\allowed_domains.acl" >> acl allowed_addresses dst "C:\squid\etc\allowed_addresses.acl" >> acl manager proto cache_object >> >> always_direct allow nocache >> http_access allow manager monitor >> http_access deny localhost >> http_access deny blocked >> http_access allow unauthenticatednet >> http_access allow allowed_domains >> http_access allow allowed_addresses > > NP: "allowed_addresses" requires DNS lookup. So slows every request > down to find the requested domains DNS entries. > Allowed addresses is actually a list of ip addresses and ranges that are allowed. I presume you mean allowed_domains which is a list of domains that are permited? In the majority of cases I can change this to use ip addresses if it will improve performance. The problem would come that in some cases I've allowed the top level domain because I want to allow all the sub domains also, mainly for applications that can't authenticate to get their updates. Is there a way round this or is the best practice to put the effort in and find the addresses for all the required subdomains as well? > http_access deny inetrestrictgroup denied_domains > > Swap those ACLs order to: > denied_domains inetrestrictgroup > > That will reduce the helper lookup load on the !denied_domains cases a > bit. > > I thought it might be worth mentioning that denied_domains is actually empty. I put it in for future use. But I have swapped these anyhow. >> http_access allow inetrestrictgroup >> http_access allow inetallowgroup >> http_access deny all >> >> cache_mem 500 MB >> maximum_object_size_in_memory 1 MB >> cache_dir ufs c:/squid/var/cache 7000 16 512 >> >> access_log C:\squid\var\logs\access.log squid. >> >> My cache log would seem to suggest that it's related to the ntlm >> helper processes. Eg >> >> /mswin_check_lm_group.exe Can't find DC for local domain 'asd' > > Your DC has disappeared, or some client is sending in a login domain > which is not yours. > Nothing the helpers can do about either case but reject. It does so, > after the horribly long lag it took to discover that problem. > It might be possible that there is a network issue but my dc is monitored by nagios and hasn't registered any issues with the checks I have in place. I'm going to see if I can audit the failed requests, which I would have hoped happened by default in active directory but apparently not. > I think this is the output of checking "deny inetrestrictgroup > denied_domains". > >> 2011/11/14 11:31:57| storeUfsCreate: Failed to create >> c:/squid/var/cache/01/C2/00058467 ((13) Permission denied) >> /mswin_check_lm_group.exe Can't find DC for local domain 'asd' > > Login checks repeat all over again. And fail again. > > I think this is the output of checking "allow inetrestrictgroup". > >> /mswin_check_lm_group.exe Can't find DC for local domain 'asd' > > Login checks repeat all over again. And fail yet again. > > I think this is the output of checking "allow inetrestrictgroup". > >> 2011/11/14 12:15:40| clientTryParseRequest: FD 361 >> (192.168.0.252:2504) Invalid Request >> 2011/11/14 12:26:41| sslWriteClient: FD 1062: write failure: (10054) >> WSAECONNRESET, Connection reset by peer.. > > And the client disconnects. > > "sslWriteClient" seems significant. Particularly since your config has > no https_port. > > What Squid version are you using? > >> >> And the cache authentication statistics seem to sugget the same > > <snip a list of client credentials. careful.> > > Well the helpers report indicates it is taking up to 25 seconds to do > *1* login request for some clients. > > > > What this looks like to me is either your DC disappearing for a short > while and Squid falling under the resulting failures. > > Or some client flooding Squid with the invalid domain name 'asd' with > the same effect. > > Amos It's version 2.7.STABLE8 As I say, I've changed to most of your suggestions and I'll see if I can get logging setup for failed login attempts on my dc. I've still got the domain names explicitly allowed though but I'll change it if there's still a problem. The domain is "asd" but it feels to me like it's a client flooding squid because I can't imagine that the DC is failing. I'll try and keep looking though. Cheers ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________
