[squid-users] Squid/NTLM Auth

Keith White keith.white at emdmillipore.com
Thu Oct 22 19:33:24 UTC 2015 

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-bounces at lists.squid-cache.org] On Behalf Of Keith White
Sent: Thursday, October 22, 2015 11:25 AM
To: Amos Jeffries <squid3 at treenet.co.nz>; squid-users at 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-bounces at lists.squid-cache.org] On Behalf Of Amos Jeffries
Sent: Thursday, October 22, 2015 4:53 AM
To: squid-users at 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 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.
_______________________________________________
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.

More information about the squid-users mailing list