RE: [squid-users] NTLM Authentication

>-----Original Message-----
>From: Amos Jeffries [mailto:squid3_at_treenet.co.nz]
>Sent: 18 November 2011 04:53
>To: squid-users_at_squid-cache.org
>Subject: Re: [squid-users] NTLM Authentication
>
>On 18/11/2011 2:23 a.m., John Sayce wrote:
>>> 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?
>
>Nope I mean "allowed_addresses". The "dst" ACL type [destinaion IP]
>does DNS lookup on the requested URL [destination domain] to find and
>match its IPs against the ACL list of IPs.
>
>
>> 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?
>
>
>"allowed_domains" is actually the better form, since Squid can test the
>ACL quickly without locating external data in DNS. If you can convert
>allowed_addresses IP entries into allowed_domains name entries that
>would be a little faster.
>
>
>
>>
>>
>>> 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.
>
>Then it can never match and even better to have it ordered first and
>save testing the whole line.
>
>>>> 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.
>
>The problem could be in DNS entries pointing Squid to the DC machine, in
>the OS somewhere loosing records linking "asd" to the DC, or in packet
>problems connecting to the DC. "Can't find" hints to me that it is one
>of the earlier two problems, that Squid helper is unable to find a DC
>machine to try connecting to.
>
>Amos

Okay I'm still getting the same problem. I haven't yet removed all the acl that use IP addresses as it will affect my users but I am speaking to them about it at the moment.

In terms of looking at whether it's a dns issue, network issue or domain controller issue. Looking at the credential validation logs on the domain controller, the requests seem to come in fairly consistently both before the issue and after I restart the service. That would suggest to me that there weren't any interuptions unless they were only for relatively brief periods of time. The logs from the domain constoller seem to show 0-20 credential validations a second. I suppose the domain contoller service could fail briefly but it seems unlikely.

I can't see any evidence of invalid credentials at the time when the problem occurs.

20 requests per second seemed quite a lot to me so I didn't know whether this was normal or an issue.

http://wiki.squid-cache.org/KnowledgeBase/NTLMAuthGoryDetails

The above makes me think this is normal due to the inherant problems with ntlm. Anyhow I looked a bit closer and if I load http://www.google.co.uk there will be about 23 requests, 9 of which will result in 407 errors.

The other thing that I was unsure about is when the error occurs it's the mswin_check_lm_group.exe process that has the error rather than the mswin_ntlm_auth.exe process. Rather than checking the user is valid it's checking that the group for that user is valid. I'm not sure if the windows security log audits this. And I'm not sure if it's relevant that the issue always occurs with the group helper rather than the authentication helper.

I have also looked deeper into when the issues occur. It seems to be when I would expect to see higher load on the server. Our users are allowed to use the internet during their lunch break for personal things, which results in higher load. The problems always seem to happen during this time.

Regards John Sayce

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________
Received on Thu Nov 24 2011 - 16:51:50 MST