Re: [squid-users] Enhancing NTLM Authentication to Remote Site Active Directory server

From: Oguz Yilmaz <oguzyilmazlist_at_gmail.com>
Date: Wed, 2 Nov 2011 15:52:05 +0200

--
Oguz YILMAZ
On Wed, Nov 2, 2011 at 1:44 AM, Amos Jeffries <squid3_at_treenet.co.nz> wrote:
> On Tue, 1 Nov 2011 11:53:34 +0200, Oguz Yilmaz wrote:
>>
>> Hi,
>>
>> We use NLTM Authentication with Squid is some setups.On hose setup
>> local machine joins active directory and squid ntlm_auth helper
>> authenticate through local samba service. Users transparently
>> authenticate through NTLM authentication handshake on HTTP without
>> entering any password in their browser.
>>
>> However, in some cases, branch offices has no local active directory
>> copy. Branch office is connected to the headquarters through a IPSEC
>> vpn. I can join the branch office samba to the headquarter active
>> directory domain and set NTLM authentication on Squid up correctly.
>>
>> This setup has a weakness inherited from high latency, packet loss of
>> some other things that I dont know about samba. 3-4 times in a day
>> users get prompted with user name password authentication popup on
>> their browser. Sometimes this recovered naturally in a few minutes.
>> However, it requires rejoining to the domain in come cases. (wbinfo -t
>> gives error and wbinfo -l can not list users).
>>
>> I have made some tunings in samba:
>>
>>   getwd cache = yes
>>   winbind cache time = 3000
>>   ldap connection timeout = 10
>>   ldap timeout = 120
>>
>> This decreased error rate to 1 per day.
>>
>> Which other tunings can I do on samba and squid? I need your experiences.
>
> Firstly, the validation lag is internal to the authentication system. Which
> consists of the helper and everything it does and uses. There is nothing
> squid can do about the auth systems internal lag. As indicated by the fact
> that tweaking samba resolved a lot of the problem.
>
Right.
>
> There are a few workarounds to avoid doing the validations by Squid though.
>
> Firstly and most preferred is to move to Negotiate/Kerberos authentication.
> It is more than twice as efficient as NTLM and offers modern security
> algorithms for much higher security.
>
>
Does Negotiate/Kerberos auth support transparent authentication for
client browsers? What is the replacement for ntlm challenge/response?
Is this the right page to start?:
http://wiki.squid-cache.org/ConfigExamples/Authenticate/Kerberos
> NTLM authentication handshake is done once per TCP connection, and applies
> only to that connection. So credentials can only be "cached" for as long as
> that TCP connection is active/persisting.
>
> Which should indicate what the fix is:
>  Get persistent connections to the clients staying up as long as possible.
> At present that means you need the latest HTTP/1.1 supporting Squid to
> maximize the keep-alive feature compliance. I recommend 3.2.0.8 if you are
> able, otherwise the latest 3.1 series, or 2.7.STABLE9 (in that order of
> preference). Avoid 3.0, 2.6 and older Squid series.
>
>>
>> Best Regards,
>>
>>
>> squid.conf:
>>
>> auth_param ntlm program /usr/bin/ntlm_auth
>> --helper-protocol=squid-2.5-ntlmssp
>> auth_param ntlm children 20
>> auth_param ntlm keep_alive off
>
> keep-alive ON.
>
>
> Also check:
>  client_persistent_connections ON
>
>
>>
>> auth_param basic program /usr/bin/ntlm_auth
>> --helper-protocol=squid-2.5-basic
>> auth_param basic children 20
>> auth_param basic realm Squid AD Auth
>> auth_param basic credentialsttl 2 hours
>> auth_param basic casesensitive off
>>
>
> Basic is checked done once per request, with credentialsttl being how often
> the backend gets checked for updates to the yes/no answer. You may be able
> to extend the credentialsttl longer for less backend checks. Impact of this
> tweak depends on how much of the client software is fialing to support NTLM
> and choosing Basic though.
>
> Amos
>
Received on Wed Nov 02 2011 - 13:52:34 MDT

This archive was generated by hypermail 2.2.0 : Thu Nov 03 2011 - 12:00:02 MDT