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
AAAACAAIADgAAAAFgomiDULzTzz40XwAAAAAAAAAAIoAigBAAAAABgEAAAAAAA9EAE4ATgBBAAIACABEAE4ATgBBAAEAFABVAFMAUwBFADEAWAAwADAAMQA0AAQAIgBuAGEA
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
Tzz40XwAAAAAAAAAAIoAigBAAAAABgEAAAAAAA9EAE4ATgBBAAIACABEAE4ATgBBAAEAFABVAFMAUwBFADEAWAAwADAAMQA0AAQAIgBuAGEALgBtAGUAcgBjAGsAZwByAG8A
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:

-----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 <squ...@treenet.co.nz>; 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 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 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


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