[squid-users] Squid/NTLM Auth

Fri Oct 23 12:44:33 UTC 2015

I changed around the DNS servers and still no luck.  This also popped up in the log

Acl.cc(70) AuthenticateAcl: returning 2 sending credentials to helper.
2015/10/23 05:41:35.259 kid1| 28,3| Acl.cc(158) matches: checked: AuthorizedUsers = -1 async
2015/10/23 05:41:35.259 kid1| 28,3| Acl.cc(158) matches: checked: http_access#3 = -1 async
2015/10/23 05:41:35.259 kid1| 28,3| Acl.cc(158) matches: checked: http_access = -1 async
2015/10/23 05:41:35.259 kid1| ERROR: NTLM Authentication validating user. Result: {result=BH, notes={message: NT_STATUS_UNSUCCESSFUL NT_STATUS_UNSUCCESSFUL; }}
2015/10/23 05:41:35.260 kid1| 29,5| UserRequest.cc(73) valid: Validated. Auth::UserRequest '0x12c1f10'.

Thanks,

Keith

-----Original Message-----
From: squid-users [mailto:squid-users-bounces at lists.squid-cache.org] On Behalf Of Keith White
Sent: Friday, October 23, 2015 8:19 AM
To: Amos Jeffries <squid3 at treenet.co.nz>; squid-users at lists.squid-cache.org
Subject: Re: [squid-users] Squid/NTLM Auth

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:squid3 at treenet.co.nz]
Sent: Thursday, October 22, 2015 11:32 PM
To: Keith White <keith.white at emdmillipore.com>; squid-users at 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 at lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

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.