subject:"\[squid\-users\] Squid\/NTLM Auth"

Re: [squid-users] Squid/NTLM Auth

2015-11-06 Thread Keith White

I ran some additional tests with ntlm_auth

ntlm_auth --usernameworks
ntlm_auth --helper-protocol=squid-2.5-ntlmssp

yields BH SPNEGO request invalid prefix

Thanks,

Keith

-Original Message-
From: Amos Jeffries [mailto:squ...@treenet.co.nz]
Sent: Monday, October 26, 2015 4:24 PM
To: Keith White ; 
squid-users@lists.squid-cache.org
Subject: Re: [squid-users] Squid/NTLM Auth

On 24/10/2015 1:44 a.m., Keith White wrote:
> 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'.
>

IIRC that BH response happens when the helper gets a type-3 token without 
having been part of the handshake dance that led up to it. The helpers are 
stateful and the same one needs to be part of the whole handshake.

That can happen if the connection is closed for some reasons after the
type-2 token is sent, and the client is brokenly continuing on a new connection 
(Firefox is known to do that, others might too).

The connection is allowed to close after the initial 407 challenge. Some 
clients are broken and require that to happen - which is where the "auth_param 
ntlm keep_alive off" setting helps.

But not once the type-2 token is sent on the second 407. Squid should be 
enforcing a persistent TCP connection from then onwards.

The nextstep is to look at either the HTTP messages or the TCP packet level to 
find out what (if anything) is closing the connection between the type-2 and 
type-3 token messages thats probably your problem.

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

Re: [squid-users] Squid/NTLM Auth

2015-11-06 Thread Keith White

I ran a couple of packet captures and I seen the 407 from the proxy back to the 
client and the corresponding NTLMSSP_AUTH from the client back to the proxy 
with my DOMAIN\USER. After this is some Kerberos traffic and then the 407 pops 
up again.

Thanks,

Keith

-Original Message-
From: Amos Jeffries [mailto:squ...@treenet.co.nz]
Sent: Monday, October 26, 2015 4:24 PM
To: Keith White ; 
squid-users@lists.squid-cache.org
Subject: Re: [squid-users] Squid/NTLM Auth

On 24/10/2015 1:44 a.m., Keith White wrote:
> 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'.
>

IIRC that BH response happens when the helper gets a type-3 token without 
having been part of the handshake dance that led up to it. The helpers are 
stateful and the same one needs to be part of the whole handshake.

That can happen if the connection is closed for some reasons after the
type-2 token is sent, and the client is brokenly continuing on a new connection 
(Firefox is known to do that, others might too).

The connection is allowed to close after the initial 407 challenge. Some 
clients are broken and require that to happen - which is where the "auth_param 
ntlm keep_alive off" setting helps.

But not once the type-2 token is sent on the second 407. Squid should be 
enforcing a persistent TCP connection from then onwards.

The nextstep is to look at either the HTTP messages or the TCP packet level to 
find out what (if anything) is closing the connection between the type-2 and 
type-3 token messages thats probably your problem.

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

Re: [squid-users] Squid/NTLM Auth

2015-10-26 Thread Amos Jeffries

On 24/10/2015 1:44 a.m., Keith White wrote:
> 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'.
> 

IIRC that BH response happens when the helper gets a type-3 token
without having been part of the handshake dance that led up to it. The
helpers are stateful and the same one needs to be part of the whole
handshake.

That can happen if the connection is closed for some reasons after the
type-2 token is sent, and the client is brokenly continuing on a new
connection (Firefox is known to do that, others might too).

The connection is allowed to close after the initial 407 challenge. Some
clients are broken and require that to happen - which is where the
"auth_param ntlm keep_alive off" setting helps.

But not once the type-2 token is sent on the second 407. Squid should be
enforcing a persistent TCP connection from then onwards.

The nextstep is to look at either the HTTP messages or the TCP packet
level to find out what (if anything) is closing the connection between
the type-2 and type-3 token messages thats probably your problem.

Amos

___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Squid/NTLM Auth

2015-10-23 Thread Keith White

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-boun...@lists.squid-cache.org] On Behalf 
Of Keith White
Sent: Friday, October 23, 2015 8:19 AM
To: Amos Jeffries ; squid-users@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:squ...@treenet.co.nz]
Sent: Thursday, October 22, 2015 11:32 PM
To: Keith White ; 
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
> CAAIADgFgomiDULzTzz40XwAAIoAigBABgEAAA9EAE4ATg
> BBAAIACABEAE4ATgBBAAEAFABVAFMAUwBFADEAWAAwADAAMQA0AAQAIgBuAGEA
> LgBtAGUAcgBjAGsAZwByAG8AdQBwAC4AYwBvAG0AAwA4AHUAcwBzAGUAMQB4ADAAMAAxADQALgBuAGEALgBtAGUAcgBjAGsAZwByAG8AdQBwAC4AYwBvAG0AAA=='
> 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 'TlRMTVNTUAACCAAIADgFgomiDULz
> Tzz40XwAAIoAigBABgEAAA9EAE4ATgBBAAIACABEAE4ATgBBAAEAFA
> BVAFMAUwBFADEAWAAwADAAMQA0AAQAIgBuAGEALgBtAGUAcgBjAGsAZwByAG8A
> dQBwAC4AYwBvAG0AAwA4AHUAcwBzAGUAMQB4ADAAMAAxADQALgBuAGEALgBtAGUAcgBjAGsAZwByAG8AdQBwAC4AYwBvAG0AAA=='!
> 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::che

Re: [squid-users] Squid/NTLM Auth

2015-10-23 Thread Keith White

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 ; 
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
> CAAIADgFgomiDULzTzz40XwAAIoAigBABgEAAA9EAE4ATg
> BBAAIACABEAE4ATgBBAAEAFABVAFMAUwBFADEAWAAwADAAMQA0AAQAIgBuAGEA
> LgBtAGUAcgBjAGsAZwByAG8AdQBwAC4AYwBvAG0AAwA4AHUAcwBzAGUAMQB4ADAAMAAxADQALgBuAGEALgBtAGUAcgBjAGsAZwByAG8AdQBwAC4AYwBvAG0AAA=='
> 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 'TlRMTVNTUAACCAAIADgFgomiDULz
> Tzz40XwAAIoAigBABgEAAA9EAE4ATgBBAAIACABEAE4ATgBBAAEAFA
> BVAFMAUwBFADEAWAAwADAAMQA0AAQAIgBuAGEALgBtAGUAcgBjAGsAZwByAG8A
> dQBwAC4AYwBvAG0AAwA4AHUAcwBzAGUAMQB4ADAAMAAxADQALgBuAGEALgBtAGUAcgBjAGsAZwByAG8AdQBwAC4AYwBvAG0AAA=='!
> 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 t

Re: [squid-users] Squid/NTLM Auth

2015-10-22 Thread Amos Jeffries

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
> CAAIADgFgomiDULzTzz40XwAAIoAigBABgEAAA9EAE4ATgBBAAIACABEAE4ATgBBAAEAFABVAFMAUwBFADEAWAAwADAAMQA0AAQAIgBuAGEA
> LgBtAGUAcgBjAGsAZwByAG8AdQBwAC4AYwBvAG0AAwA4AHUAcwBzAGUAMQB4ADAAMAAxADQALgBuAGEALgBtAGUAcgBjAGsAZwByAG8AdQBwAC4AYwBvAG0AAA=='
> 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 'TlRMTVNTUAACCAAIADgFgomiDULz
> Tzz40XwAAIoAigBABgEAAA9EAE4ATgBBAAIACABEAE4ATgBBAAEAFABVAFMAUwBFADEAWAAwADAAMQA0AAQAIgBuAGEALgBtAGUAcgBjAGsAZwByAG8A
> dQBwAC4AYwBvAG0AAwA4AHUAcwBzAGUAMQB4ADAAMAAxADQALgBuAGEALgBtAGUAcgBjAGsAZwByAG8AdQBwAC4AYwBvAG0AAA=='!
> 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
 to see what type
they are.

Amos

___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Squid/NTLM Auth

2015-10-22 Thread Keith White

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
CAAIADgFgomiDULzTzz40XwAAIoAigBABgEAAA9EAE4ATgBBAAIACABEAE4ATgBBAAEAFABVAFMAUwBFADEAWAAwADAAMQA0AAQAIgBuAGEA
LgBtAGUAcgBjAGsAZwByAG8AdQBwAC4AYwBvAG0AAwA4AHUAcwBzAGUAMQB4ADAAMAAxADQALgBuAGEALgBtAGUAcgBjAGsAZwByAG8AdQBwAC4AYwBvAG0AAA=='
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 'TlRMTVNTUAACCAAIADgFgomiDULz
Tzz40XwAAIoAigBABgEAAA9EAE4ATgBBAAIACABEAE4ATgBBAAEAFABVAFMAUwBFADEAWAAwADAAMQA0AAQAIgBuAGEALgBtAGUAcgBjAGsAZwByAG8A
dQBwAC4AYwBvAG0AAwA4AHUAcwBzAGUAMQB4ADAAMAAxADQALgBuAGEALgBtAGUAcgBjAGsAZwByAG8AdQBwAC4AYwBvAG0AAA=='!
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:

-Original Message-
From: squid-users [mailto:squid-users-boun...@lists.squid-cache.org] On Behalf 
Of Keith White
Sent: Thursday, October 22, 2015 11:25 AM
To: Amos Jeffries ; squid-users@lists.squid-cache.org
Subject: Re: [squid-users] Squid/NTLM Auth

I was able to confirm that ntlm_auth worked for the squid user.  We currently 
use BlueCoat proxies so IE is definitely configured to use integrated 
authentication. No cache_effective* in the config.  I will enable debugging and 
see what is happening as well as enable Kerberos.

Thanks,

Keith

-Original Message-
From: squid-users [mailto:squid-users-boun...@lists.squid-cache.org] On Behalf 
Of Amos Jeffries
Sent: Thursday, October 22, 2015 4:53 AM
To: squid-users@lists.squid-cache.org
Subject: Re: [squid-users] Squid/NTLM Auth

On 22/10/2015 8:21 a.m., Keith White wrote:
>
> I have squid running on Centos 7 and am trying to setup AD
> authentication. I have samba/winbindd installed and the system was
> added to the domain with authconfig. I have tested authentication with
> auth_ntlm and that works. I have also tested group membership with
> auth_ntlm and that works as well. When attempting to access squid

Re: [squid-users] Squid/NTLM Auth

2015-10-22 Thread Keith White

I was able to confirm that ntlm_auth worked for the squid user.  We currently 
use BlueCoat proxies so IE is definitely configured to use integrated 
authentication. No cache_effective* in the config.  I will enable debugging and 
see what is happening as well as enable Kerberos.

Thanks,

Keith

-Original Message-
From: squid-users [mailto:squid-users-boun...@lists.squid-cache.org] On Behalf 
Of Amos Jeffries
Sent: Thursday, October 22, 2015 4:53 AM
To: squid-users@lists.squid-cache.org
Subject: Re: [squid-users] Squid/NTLM Auth

On 22/10/2015 8:21 a.m., Keith White wrote:
>
> I have squid running on Centos 7 and am trying to setup AD
> authentication. I have samba/winbindd installed and the system was
> added to the domain with authconfig. I have tested authentication with
> auth_ntlm and that works. I have also tested group membership with
> auth_ntlm and that works as well. When attempting to access squid with
> either IE or Firefox I am presented with the authentication dialog box.

If you have cache_effective_user or cache_effective_group directives in your 
config file remove them. They break the Winbind helpers group permissions.

Were your successful tests made using the Squid low-privileged user account ?
 If no, then your test results are not relevant. Re-test as the Squid user. 
Which will need membership of the winbindd_priv group.

What Windows version are the IE and Firefox being run on?
If it is newer than Windows 2000, then you should be moving to 
Negotiate/Kerberos authentication instead of NTLM.

Does the client machine have Windows Integrated Authentication enabled?
and is it on-domain?
 Off-domain machines have no chance of NTLM working. Disable their integrated 
authentication settings.
Note that without the integrated auth Firefox has no access to NTLM credentials 
and MSIE has a tendency to use the machine credentials instead of the users.

> Manually entering credentials does not work. What debugging can I
> enable to see what is going on? Squid is built with the following

<http://wiki.squid-cache.org/KnowledgeBase/DebugSections>

At least these:
  debug_options ALL,0 11,2 28,5 29,5

>
> Squid Cache: Version 3.5.9-20150917-r13917 Service Name: squid
> configure options:  '--prefix=/usr' '--includedir=/usr/include' 
> '--datadir=/usr/share' '--bindir=/usr/sbin' '--libexecdir=/usr/lib/squid' 
> '--localstatedir=/varsquid' '--sysconfdir=/etc/squid' '--enable-auth' 
> '--enable-auth-ntlm' '--enable-external-acl-helpers' 
> '--enable-auth-negotiate' '--enable-auth-basic' '--enable-auth-digest'
>
>
> relevant section from squid.conf
>
> auth_param ntlm program /usr/bin/ntlm_auth --diagnostics
> --helper-protocol=squid-2.5-ntlmssp
> auth_param ntlm children 5
> auth_param ntlm keep_alive on
> auth_param basic program /usr/bin/ntlm_auth --diagnostics
> --helper-protocol=squid-2.5-basic auth_param basic children 5
> auth_param basic realm Squid proxy-caching web server auth_param basic
> credentialsttl 2 hours

You should list Basic as first choice since it is the more secure of those two 
protocols.

Sounds like a joke, but it is true NTLM is less secure these days than Basic 
auth. Namely because clients that accept NTLM can be auto-downgraded by 
attackers to using LanMan protocols that broadcast the username and password 
just like Basic - BUT most network software treats Basic auth as the insecure 
one and do a lot more to protect its weak credentials.

>
> acl AuthorizedUsers proxy_auth REQUIRED http_access allow localnet
> http_access allow AuthorizedUsers http_access allow localhost

The above implies that the authenticated users will be outside the LAN 
(localnet). The 'L' in NTLM is "LAN" and old 1980-1990's style flat LAN 
networks are where it was designed for use. It does *not* work properly over 
Internet connections or even in many of todays complex LAN environments.

You need Negotiate/Kerberos auth for Internet clients to even have half a 
chance of authenticating securely. Then you also need to get the whole on/off 
domain thing sorted out and working.

PS. you will probably need a few hundred helpers for NTLM. It is an
*extremely* inefficient protocol. I've not seen even a home network operate 
with less than 50, usual minimum is 100.

Amos
___
squid-users mailing list
squid-users@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

Re: [squid-users] Squid/NTLM Auth

2015-10-22 Thread Amos Jeffries

On 22/10/2015 8:21 a.m., Keith White wrote:
> 
> I have squid running on Centos 7 and am trying to setup AD
> authentication. I have samba/winbindd installed and the system was added
> to the domain with authconfig. I have tested authentication with
> auth_ntlm and that works. I have also tested group membership with
> auth_ntlm and that works as well. When attempting to access squid with
> either IE or Firefox I am presented with the authentication dialog box.

If you have cache_effective_user or cache_effective_group directives in
your config file remove them. They break the Winbind helpers group
permissions.

Were your successful tests made using the Squid low-privileged user
account ?
 If no, then your test results are not relevant. Re-test as the Squid
user. Which will need membership of the winbindd_priv group.

What Windows version are the IE and Firefox being run on?
If it is newer than Windows 2000, then you should be moving to
Negotiate/Kerberos authentication instead of NTLM.

Does the client machine have Windows Integrated Authentication enabled?
and is it on-domain?
 Off-domain machines have no chance of NTLM working. Disable their
integrated authentication settings.
Note that without the integrated auth Firefox has no access to NTLM
credentials and MSIE has a tendency to use the machine credentials
instead of the users.

> Manually entering credentials does not work. What debugging can I enable
> to see what is going on? Squid is built with the following

At least these:
  debug_options ALL,0 11,2 28,5 29,5

> 
> Squid Cache: Version 3.5.9-20150917-r13917
> Service Name: squid
> configure options:  '--prefix=/usr' '--includedir=/usr/include' 
> '--datadir=/usr/share' '--bindir=/usr/sbin' '--libexecdir=/usr/lib/squid' 
> '--localstatedir=/varsquid' '--sysconfdir=/etc/squid' '--enable-auth' 
> '--enable-auth-ntlm' '--enable-external-acl-helpers' 
> '--enable-auth-negotiate' '--enable-auth-basic' '--enable-auth-digest'
> 
> 
> relevant section from squid.conf
> 
> auth_param ntlm program /usr/bin/ntlm_auth --diagnostics 
> --helper-protocol=squid-2.5-ntlmssp
> auth_param ntlm children 5
> auth_param ntlm keep_alive on
> auth_param basic program /usr/bin/ntlm_auth --diagnostics 
> --helper-protocol=squid-2.5-basic
> auth_param basic children 5
> auth_param basic realm Squid proxy-caching web server
> auth_param basic credentialsttl 2 hours

You should list Basic as first choice since it is the more secure of
those two protocols.

Sounds like a joke, but it is true NTLM is less secure these days than
Basic auth. Namely because clients that accept NTLM can be
auto-downgraded by attackers to using LanMan protocols that broadcast
the username and password just like Basic - BUT most network software
treats Basic auth as the insecure one and do a lot more to protect its
weak credentials.

> 
> acl AuthorizedUsers proxy_auth REQUIRED
> http_access allow localnet
> http_access allow AuthorizedUsers
> http_access allow localhost

The above implies that the authenticated users will be outside the LAN
(localnet). The 'L' in NTLM is "LAN" and old 1980-1990's style flat LAN
networks are where it was designed for use. It does *not* work properly
over Internet connections or even in many of todays complex LAN
environments.

You need Negotiate/Kerberos auth for Internet clients to even have half
a chance of authenticating securely. Then you also need to get the whole
on/off domain thing sorted out and working.

PS. you will probably need a few hundred helpers for NTLM. It is an
*extremely* inefficient protocol. I've not seen even a home network
operate with less than 50, usual minimum is 100.

Amos
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

[squid-users] Squid/NTLM Auth

2015-10-21 Thread Keith White

I have squid running on Centos 7 and am trying to setup AD authentication.  I 
have samba/winbindd installed and the system was added to the domain with 
authconfig.  I have tested authentication with auth_ntlm and that works. I have 
also tested group membership with auth_ntlm and that works as well.  When 
attempting to access squid with either IE or Firefox I am presented with the 
authentication dialog box.  Manually entering credentials does not work.  What 
debugging can I enable to see what is going on?  Squid is built with the 
following

Squid Cache: Version 3.5.9-20150917-r13917
Service Name: squid
configure options:  '--prefix=/usr' '--includedir=/usr/include' 
'--datadir=/usr/share' '--bindir=/usr/sbin' '--libexecdir=/usr/lib/squid' 
'--localstatedir=/varsquid' '--sysconfdir=/etc/squid' '--enable-auth' 
'--enable-auth-ntlm' '--enable-external-acl-helpers' '--enable-auth-negotiate' 
'--enable-auth-basic' '--enable-auth-digest'


relevant section from squid.conf

auth_param ntlm program /usr/bin/ntlm_auth --diagnostics 
--helper-protocol=squid-2.5-ntlmssp
auth_param ntlm children 5
auth_param ntlm keep_alive on
auth_param basic program /usr/bin/ntlm_auth --diagnostics 
--helper-protocol=squid-2.5-basic
auth_param basic children 5
auth_param basic realm Squid proxy-caching web server
auth_param basic credentialsttl 2 hours

acl AuthorizedUsers proxy_auth REQUIRED
http_access allow localnet
http_access allow AuthorizedUsers
http_access allow localhost


Thanks,

Keith





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

Re: [squid-users] Squid/NTLM Auth

Re: [squid-users] Squid/NTLM Auth

Re: [squid-users] Squid/NTLM Auth

Re: [squid-users] Squid/NTLM Auth

Re: [squid-users] Squid/NTLM Auth

Re: [squid-users] Squid/NTLM Auth

Re: [squid-users] Squid/NTLM Auth

Re: [squid-users] Squid/NTLM Auth

Re: [squid-users] Squid/NTLM Auth

[squid-users] Squid/NTLM Auth

10 matches

Site Navigation

Mail list logo

Footer information