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


Reply via email to