I reran the test and checked the tokens and I can see the type 1 and type 2 
tokens but no type 3 tokens.  I ran a packet capture and I think I may have 
found the issue.  Our Windows servers are specifically configured to not 
resolve external DNS names.  To get around that I configured specific DNS 
servers in Squid.  These servers are not AD DNS servers and it appears when 
Squid is trying to authenticate, it is using these servers and not the DNS 
servers in /etc/resolv.conf (these point to Windows). I am going to play around 
with the DNS servers to see if the behavior changes.

Thanks,

Keith

-----Original Message-----
From: Amos Jeffries [mailto:squ...@treenet.co.nz]
Sent: Thursday, October 22, 2015 11:32 PM
To: Keith White <keith.wh...@emdmillipore.com>; 
squid-users@lists.squid-cache.org
Subject: Re: [squid-users] Squid/NTLM Auth

On 23/10/2015 8:33 a.m., Keith White wrote:
> Added the debug options and grabbed the following after the 407 message was 
> returned to the client.  Is there anything specific I should be looking for?
>
> Thanks,
>
> Keith
>
>
> 2015/10/22 12:24:50.573 kid1| Starting new ntlmauthenticator helpers...
> 2015/10/22 12:24:50.574 kid1| 28,4| Acl.cc(70) AuthenticateAcl: returning 2 
> sending credentials to helper.
> 2015/10/22 12:24:50.574 kid1| 28,3| Acl.cc(158) matches: checked:
> AuthorizedUsers = -1 async
> 2015/10/22 12:24:50.574 kid1| 28,3| Acl.cc(158) matches: checked:
> http_access#3 = -1 async
> 2015/10/22 12:24:50.574 kid1| 28,3| Acl.cc(158) matches: checked:
> http_access = -1 async
> 2015/10/22 12:24:50.618 kid1| 29,4| UserRequest.cc(303) HandleReply:
> Need to challenge the client with a server token: 'TlRMTVNTUAAC
> AAAACAAIADgAAAAFgomiDULzTzz40XwAAAAAAAAAAIoAigBAAAAABgEAAAAAAA9EAE4ATg
> BBAAIACABEAE4ATgBBAAEAFABVAFMAUwBFADEAWAAwADAAMQA0AAQAIgBuAGEA
> LgBtAGUAcgBjAGsAZwByAG8AdQBwAC4AYwBvAG0AAwA4AHUAcwBzAGUAMQB4ADAAMAAxADQALgBuAGEALgBtAGUAcgBjAGsAZwByAG8AdQBwAC4AYwBvAG0AAAAAAA=='
> 2015/10/22 12:24:50.618 kid1| 29,5| UserRequest.cc(73) valid: Validated. 
> Auth::UserRequest '0xfb5870'.
> 2015/10/22 12:24:50.618 kid1| 28,5| InnerNode.cc(94) resumeMatchingAt:
> checking http_access at 2
> 2015/10/22 12:24:50.618 kid1| 28,5| Checklist.cc(400) bannedAction:
> Action 'ALLOWED/0is not banned
> 2015/10/22 12:24:50.618 kid1| 28,5| InnerNode.cc(94) resumeMatchingAt:
> checking http_access#3 at 0
> 2015/10/22 12:24:50.618 kid1| 28,5| Acl.cc(138) matches: checking
> AuthorizedUsers
> 2015/10/22 12:24:50.618 kid1| 29,5| UserRequest.cc(73) valid: Validated. 
> Auth::UserRequest '0xfb5870'.
> 2015/10/22 12:24:50.618 kid1| 29,5| UserRequest.cc(73) valid: Validated. 
> Auth::UserRequest '0xfb5870'.
> 2015/10/22 12:24:50.618 kid1| 29,2| UserRequest.cc(194) authenticate:
> need to challenge client 'TlRMTVNTUAACAAAACAAIADgAAAAFgomiDULz
> Tzz40XwAAAAAAAAAAIoAigBAAAAABgEAAAAAAA9EAE4ATgBBAAIACABEAE4ATgBBAAEAFA
> BVAFMAUwBFADEAWAAwADAAMQA0AAQAIgBuAGEALgBtAGUAcgBjAGsAZwByAG8A
> dQBwAC4AYwBvAG0AAwA4AHUAcwBzAGUAMQB4ADAAMAAxADQALgBuAGEALgBtAGUAcgBjAGsAZwByAG8AdQBwAC4AYwBvAG0AAAAAAA=='!
> 2015/10/22 12:24:50.618 kid1| 29,5| UserRequest.cc(73) valid: Validated. 
> Auth::UserRequest '0xfb5870'.
> 2015/10/22 12:24:50.618 kid1| 28,4| Acl.cc(76) AuthenticateAcl: returning 3 
> sending authentication challenge.
> 2015/10/22 12:24:50.618 kid1| 28,3| Checklist.cc(63) markFinished:
> 0x13d56f8 answer AUTH_REQUIRED for AuthenticateAcl exception
> 2015/10/22 12:24:50.618 kid1| 28,3| Acl.cc(158) matches: checked:
> AuthorizedUsers = -1
> 2015/10/22 12:24:50.618 kid1| 28,3| InnerNode.cc(97) resumeMatchingAt:
> checked: http_access#3 = -1
> 2015/10/22 12:24:50.618 kid1| 28,3| InnerNode.cc(97) resumeMatchingAt:
> checked: http_access = -1
> 2015/10/22 12:24:50.618 kid1| 28,3| Checklist.cc(163) checkCallback:
> ACLChecklist::checkCallback: 0x13d56f8 answer=AUTH_REQUIRED
> 2015/10/22 12:24:50.618 kid1| 28,4| FilledChecklist.cc(66)
> ~ACLFilledChecklist: ACLFilledChecklist destroyed 0x7ffc19f8a3d0
> 2015/10/22 12:24:50.618 kid1| 28,4| Checklist.cc(197) ~ACLChecklist:
> ACLChecklist::~ACLChecklist: destroyed 0x7ffc19f8a3d0
> 2015/10/22 12:24:50.618 kid1| 28,4| FilledChecklist.cc(66)
> ~ACLFilledChecklist: ACLFilledChecklist destroyed 0x7ffc19f8a3d0
> 2015/10/22 12:24:50.618 kid1| 28,4| Checklist.cc(197) ~ACLChecklist:
> ACLChecklist::~ACLChecklist: destroyed 0x7ffc19f8a3d0
> 2015/10/22 12:24:50.619 kid1| 29,5| UserRequest.cc(73) valid: Validated. 
> Auth::UserRequest '0xfb5870'.
> 2015/10/22 12:24:50.619 kid1| 11,2| client_side.cc(1391)
> sendStartOfMessage: HTTP Client local=10.31.78.10:3128
> remote=10.1.4.1:5917
> 6 FD 11 flags=1
> 2015/10/22 12:24:50.619 kid1| 11,2| client_side.cc(1392) sendStartOfMessage: 
> HTTP Client REPLY:
>

That is the type-2 tokens happening. There should be an initial client request 
and 407, then repeat client request with type-1 tokens leading up to this.

The details of that reply message you elided at the end should match the 
challenge token, and contain Connection:keep-alive.

Then there is the followup client re-request with type-3 tokens. And the 
servers final reply should accept that type-3 token. Ideally it should also use 
Connection:keep-alive.

If either of those two latter transactions contains Connection:close from 
either endpoint NTLM breaks.


You can drop the tokens into
<http://treenet.co.nz/projects/squid/ntlm_token.php> to see what type they are.

Amos



This message and any attachment are confidential and may be privileged or 
otherwise protected from disclosure. If you are not the intended recipient, you 
must not copy this message or attachment or disclose the contents to any other 
person. If you have received this transmission in error, please notify the 
sender immediately and delete the message and any attachment from your system. 
Merck KGaA, Darmstadt, Germany and any of its subsidiaries do not accept 
liability for any omissions or errors in this message which may arise as a 
result of E-Mail-transmission or for damages resulting from any unauthorized 
changes of the content of this message and any attachment thereto. Merck KGaA, 
Darmstadt, Germany and any of its subsidiaries do not guarantee that this 
message is free of viruses and does not accept liability for any damages caused 
by any virus transmitted therewith.



Click http://www.merckgroup.com/disclaimer to access the German, French, 
Spanish and Portuguese versions of this disclaimer.
_______________________________________________
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Reply via email to