RE: [squid-users] NTLM, non-domain machines and keep-alive

Hi!

I did a acl noauth for dst domains and noauth for src with hosts/urls that wont work with auth :/

acl noauth dstdom_regex -i "/etc/squid/noauth_dstdom/noauth"

acl client srcdom_regex -i "/etc/squid/noauth/client"

this line before the "acl domainusers proxy_auth REQUIRED"
http_access allow noauth client

// Anders

 * Systemadmin Unix/Linux/Vmware
 * Tieto
 * Kyrkgatan 60
 * 831 34 ÖSTERSUND
 * Växel: +46 (0)10 481 98 00
 * Fax: +46 (0)10 481 98 10
 * Tel: +46 (0)10 481 02 20
 * Mobil: +46 (0)70 656 42 64
 * Mail: anders.larsson_at_tieto.com
 **********************************************
  
  ---- Debian is they way to salvation ----
  
  --- How Hard Can It Be ---

-----Original Message-----
From: Harry Mills [mailto:harry_at_mad-cat.co.uk]
Sent: den 9 maj 2012 11:06
To: squid-users_at_squid-cache.org
Subject: Re: [squid-users] NTLM, non-domain machines and keep-alive

Hi,

I am still unsure why IE and Chrome would pop up an authentication box 3
times (rather than just once) when they are not a member of the domain.
I would certainly expect a box to pop up - but why three times?!

When I was testing with just NTLM as the authentication mechanism I set:

auth_param ntlm keep-alive off

This solved the 3-popup problem and IE just pops up one authentication box.

We are now using the negotiate_wrapper around Kerberos and NTLM, which
is working very well - except we still have the multi-authentication
boxes popping up for non-domain windows machines.

Can I set the same parameter for negotiate:

auth_param negotiate keep-alive off

or will have undesirable effects on Negotiate mechanism?

If this is not a solution, is there another area I should be looking at
as to why we are getting 3 popup boxes in a row when non-domain machines
try to authenticate with Squid?

Regards

Harry

On 20/04/2012 19:29, Harry Mills wrote:
> Hi,
>
> Firstly, thank you Amos for helping out here. I am finding it rather
> frustrating because I have enough knowledge on this subject get myself
> into trouble, but not enough to get myself back out of it!
>
> On 20/04/2012 14:58, Amos Jeffries wrote:
>> On 20/04/2012 12:03 a.m., Harry Mills wrote:
>>> Hi,
>>>
>>> I have upgraded our squid to version 3.1.19 but I am still seeing the
>>> repeated popup box issue with non-domain member machines (windows
>>> machines).
>>>
>>
>> Well, yes. Lookup the requriements for NTLM with actual security
>> enabled. #1 on the list is "join the client machine to domain" or some
>> wording to that effect.
>
> This can be very frustrating! The problems I am facing are really caused
> by the fact that Windows clients, when presented with "negotiate" as an
> authentication option will choose NTLM when they are not members of the
> domain. This would be fine if they simply popped up a box *once* for the
> credentials, but having to type DOMAIN\username and a password three
> times before you are allowed access is difficult to explain to end users!
>
>> NTLM and its relative are domain-based authentication protocols, with a
>> centralized controller system. You are trying to make machines outside
>> the domain with no access to the DC secrets able to generate tokens
>> based on those secrets.
>>
>> It used to "work" for NTLMv1 because it has a failure recovery action
>> which drops back to LM protocol which is frighteningly like Basic auth
>> protocol without any domain secrets to validate the machine is allowed
>> to be logged in with. None of the modern software permits that LM mode
>> to be used anymore without some manual security disabling.
>
> I realise something has changed because our previous ( 4 years older )
> squid with NTLM worked in exactly the way I would have expected. NTLM
> working for all domain machines, and a *single* popup authentication box
> for those clients which were not domain members - to be honest, I always
> assumed that the single authentication box was the browser falling back
> to Basic auth because it couldn't use NTLM.
>
>>> Domain member machines authenticate perfectly via NTLM, but non-domain
>>> member machines (Windows XP, Windows 7) pop up a password box three
>>> times before accepting the credentials.
>>>
>>> I have removed all the authentication directives _except_ the NTLM one
>>> to simplify the troubleshooting.
>>>
>>> If I asked Internet Explorer to save the credentials then the
>>> authentication works fine and I get no further popup boxes. Chrome is
>>> the same - as is Firefox, although interestingly Firefox will only
>>> authenticate if the credentials have been stored. If they have not
>>> been stored (using IE remember password) it plain refuses to
>>> authenticate at all (no popup boxes or anything).
>>
>> Wow strange behaviour from Firefox, do they have a bug report about this?
>
> I have not come across one, but will check and present one if not.
>
>> The others are correct for a non-domain machine. When connected to a
>> domain the machine can validate that the requested NTLM domain/realm is
>> the same as the machien login one and use that for single-sign-on.
>> Without an existing domain login or pre-stored domain credentials to use
>> it is only to be expected the browser asks for popup to be filled out by
>> the user.
>
> I realise the popup is necessary as there are no domain credentials to
> use, my confusion was that it pops up three times, my (probably
> confused) logic is that it should only need to ask once!
>
>>> I am more than happy to work through this myself, but have exhausted
>>> all my ideas. Could some one point me in the right direction?
>>
>> While keep-alive / persistent connections *is* mandatory for NTLM to
>> work. The "auth_param ntlm keep-alive off" setting is a kind of special
>> adaptation to keep-alive, which sends the challenge signalling NTLM then
>> drops the connection. Forcing the client to open a new connection and
>> start it with the auth handshake requests. Once the handshake is started
>> the normal persistence settings take over.
>>
>> It is a bit nasty and somewhat confusing. But thats the best we can do
>> with certain software.
>
> Thank you for that explanation - it is confusing! All I really want to
> achieve is single-signon for the domain members, and a *single* password
> popup for non-domain members.
>
> Thank you again for your help.
>
> Regards
>
> Harry
>
>
>> Amos
>>
>
Received on Wed May 09 2012 - 10:06:50 MDT