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

From: Harry Mills <harry_at_mad-cat.co.uk>
Date: Fri, 20 Apr 2012 19:29:36 +0100

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 Fri Apr 20 2012 - 18:27:20 MDT

This archive was generated by hypermail 2.2.0 : Sat Apr 21 2012 - 12:00:04 MDT