Re: [squid-users] Authenticating to sharepoint NTLM

On 19.04.2012 12:09, Javier Conti wrote:
> On 19 April 2012 02:01, Brett Lymn wrote:
>> On Wed, Apr 18, 2012 at 11:18:05PM +0200, Javier Conti wrote:
>>>
>>> It is known for Windows 7 (I don't know about Linux clients) to
>>> behave
>>> differently from Windows XP.
>>>
>>
>> If you are using samba for the authentication then perhaps adding:
>>
>> server signing = auto
>>
>> to the smb.conf will help.  By default Win 7 uses SMB signing, if
>> you
>> put this option on then samba will check if SMB signing is being
>> used
>> and respond appropriately.  This obviates the need for trying to
>> tweak
>> the Win 7 security settings down which really is a losing
>> proposition
>> since every time you rebuild the Win 7 client machine you have to
>> remember to
>> redo the security tweak or your environment may simply not allow you
>> to
>> adjust these settings.
>
> Where should I put this setting? On the Squid server?
>
> In my case, the LAB Squid through which I'm going is at the moment
> completely open. By the way, if I try Kerberos, NTLM or plain auth
> against the
> proxy itself, it works fine. It's just Windows 7 against IIS with IWA
> through the
> proxy that doesn't work. I don't think it's related, unless I'm
> missing something...
>

IWA and NTLM auth are two different things.

IWA is "just" the API in Windows used to fetch credentials. It defaults
to a minimal security level (NTLMv1 for older Windows 2k etc, NTLMv2 for
Windows XP, Kerberos for Windows 7, etc). But any type of credentials
are available through it, even Basic auth credentials if the Domain is
setup to allow that.

NTLM is a *collection* of a good dozen auth protocols sharing a binary
syntax. They are grouped into four generational types: LM , NTLMv1,
NTLMv2, and Kerberos. With most of the ancient protocol types coming
under "LM" banner. Each version of Windows uses a slightly different
set.

Now, Squid has nothing to do with any of that complex layer beyond
shuffling the WWW-Auth credentials from client to server and pinning the
TCP connections to prevent HTTP multiplexing and pipelining. Possibly
passing to the helpers if its Proxy-Auth. A lot of the actual failure
problems with NTLM hang around persistent connections not working or the
Windows version accepted security levels not overlapping (aka which
sub-protocol is supported).

Given that you have other systems working with NTLM or Kerberos through
the proxy its a good sign that the proxy connections are working and
setup right. BUT, the specific client system is also involved in
connection persistence. If either end is prematurely closing the TCP
links it will all fail badly.
  If that appears to be behaving the same with keep-alive, it is most
likely a NTLM sub-protocol problem. For that you will need to go deep
into a packet trace to figure out which sub-protocol(s) each end of the
client-->server system is offering to use and see where the difference
is.

Amos
Received on Thu Apr 19 2012 - 02:02:32 MDT