Search squid archive

NTLM, non-domain machines and keep-alive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

I have been trying to iron our a few issues we are having with NTLM authentication on our network for machines which are not domain members:

Windows 2008R2 AD domain
RHEL 6.1
squid-3.1.10-1
samba-3.5.6-86
Internet Explorer 7,8

We are in the process of moving to Kerberos authentication, and the test squid we have running is working well, however, when presented with the negotiate option for auth, IE will choose NTLM rather than basic when it is not a member of the domain.

I have reduced the config for squid down to just offering NTLM authentication to help me debug an issue with pop up boxes. I have also written a wrapper around the ntlm_auth binary to strace the calls being made when it is being executed.

NTLM authentication works without issue for domain members, however IE (and Chrome) will both popup an authentication required box three times before accepting the DOMAIN\Username and password.

Checking the wrapper around ntlm_auth, the process is only called by squid after the last of the three authentication prompts is submitted by the browser. Squid issues the expected two 407s to the browser which appears to cause the browser to pop up the authentication window each time, and on the third submission authentication succeeds.

The odd thing is, if I turn off keep-alive for ntlm in the squid.conf then I still see the 407s being issued by squid, but I only get a single authentication pop up from the browser, which when submitted with the correct credentials is immediately accepted and authentication succeeds.

I am clearly missing something, because it states quite clearly that NTLM _requires_ keep alive sockets as it is a connection orientated mechanism, so perhaps my turning off keep-alive causes a basic-auth fallback within ntlm_auth?

Is there a reason that IE presents 3 authentication boxes before accepting credentials from a non-domain machine. If there is a reason, is there a solution?

One thought I have had is that the majority of non-domain members will be on a specific VLAN, and therefore have a specific IP subnet. Is it possible to offer a different range of authentication options to the clients based on a subnet acl, e.g. Kerb/NTLM for machines on domain-member VLANS and just basic for guests (non-domain members)?

Regards,

Harry


[Index of Archives]     [Linux Audio Users]     [Samba]     [Big List of Linux Books]     [Linux USB]     [Yosemite News]

  Powered by Linux