The Story of secure user-authentication in squid

Solution 1:

Kerberos is not an option for HTTP authentication. NTLM is not well supported in any browser other than IE. Basic is not secure unless you put it behind HTTPS which AFAIK squid cannot do. So you are left with Digest.

Solution 2:

One interesting feature that could help you here is that the method Squid uses to ask the client browser for authentication (path A) does not need at all to be related to the method it uses to actually validate the credentials supplied by the user (path B). This means, f.e., that you can make Squid "talk" NTLM with client browsers, but then it could very well validate users against Linux's internal user database (/etc/passwd). There is no need for credentials acquired using NTLM (on path A) to actually be validated against a Windows domain (on path B). The same applies to any possible combination of client-side authentication methods and server-side authentication ones.

What this means in your case, is that f.e. you can safely configure Squid to request NTLM authentication from client browsers instead of basic authentication, and this will not in any way require you to actually use Samba/WinBind/AD/whatever.

So you can choose whatever method you want for client-side authentication, yet still keep validating users against a LDAP server after they provided their credentials using the method you selected.

The magic happens, of course, in squid.conf:

#auth_param negotiate program <uncomment and complete this line to activate>
#auth_param negotiate children 5
#auth_param negotiate keep_alive on
#auth_param ntlm program <uncomment and complete this line to activate>
#auth_param ntlm children 5
#auth_param ntlm keep_alive on
#auth_param digest program <uncomment and complete this line>
#auth_param digest children 5
#auth_param digest realm Squid proxy-caching web server
#auth_param digest nonce_garbage_interval 5 minutes
#auth_param digest nonce_max_duration 30 minutes
#auth_param digest nonce_max_count 50
#auth_param basic program <uncomment and complete this line>
#auth_param basic children 5
#auth_param basic realm Squid proxy-caching web server
#auth_param basic credentialsttl 2 hours
#auth_param basic casesensitive off

Each auth_param directive enables a specific authentication for client browsers (path A), while the "program" part sets what Squid will actually use to validate the credentials provided by users. You can use whatever authenticator program you want here (even a custom-written one), as long as it can receive a user id and a password and answer "yes" or "no".

You just need to take whatever authenticator you're using to do your LDAP query and stick it into the "auth_param ntlm" or "auth_param digest" statements, instead of the "auth_param basic" one where it is now.

Update:

You should definitely use squid_ldap_auth as your authenticator, but I can't tell you exactly how without any detail about the specific LDAP server you're using.

Regarding client-side authentication, any one should be good; I'm quite happy with NTLM, and most browsers support it nowadays.

Such a configuration would look like this in squid.conf:

auth_param ntlm program /usr/lib/squid/squid_ldap_auth <parameters>

This will ask for user credentials (path A) using NTLM, then validate them against a LDAP server (path B); but those "parameters" strictly depend on your LDAP implementation and configuration.

This could help, too: http://www.cyberciti.biz/tips/howto-configure-squid-ldap-authentication.html.