April 4, 2009 Leave a comment
How does Proxy Authentication work in Squid?
Users will be authenticated if squid is configured to use proxy_auth ACLs.
Browsers send the user’s authentication credentials in the Authorization request header.
If Squid gets a request and the http_access rule list gets to a proxy_auth ACL, Squid looks for the Authorization header. If the header is present, Squid decodes it and extracts a username and password.
If the header is missing, Squid returns an HTTP reply with status 407 (Proxy Authentication Required). The user agent (browser) receives the 407 reply and then prompts the user to enter a name and password. The name and password are encoded, and sent in the Authorization header for subsequent requests to the proxy. Also see this example Authorization Header from .htaccess files.
NOTE: The name and password are encoded using “base64″ (See section 11.1 of RFC 2616). However, base64 is a binary-to-text encoding only, it does NOT encrypt the information it encodes. This means that the username and password are essentially “cleartext” between the browser and the proxy. Therefore, you probably should not use the same username and password that you would use for your account login.
Authentication is actually performed outside of main Squid process. When Squid starts, it spawns a number of authentication subprocesses. These processes read usernames and passwords on stdin, and reply with “OK” or “ERR” on stdout. This technique allows you to use a number of different authentication protocols (named “schemes” in this context). When multiple authentication schemes are offered by the server (Squid in this case), it is up to the User-Agent to choose one and authenticate using it. By RFC it should choose the safest one it can handle; in practice usually Microsoft Internet Explorer chooses the first one it’s been offered that it can handle, and Mozilla browsers are bug-compatible with the Microsoft system in this field.
The Squid source code comes with a few authentication backends (“helpers“) for Basic authentication. These include:
- LDAP: Uses the Lightweight Directory Access Protocol
- NCSA: Uses an NCSA-style username and password file.
- MSNT: Uses a Windows NT authentication domain.
- PAM: Uses the Unix Pluggable Authentication Modules scheme.
- SMB: Uses a SMB server like Windows NT or Samba.
- getpwam: Uses the old-fashioned Unix password file.
- SASL: Uses SALS libraries.
- mswin_sspi: Windows native authenticator
- YP: Uses the NIS database
In addition Squid also supports the NTLM, Negotiate and Digest authentication schemes which provide more secure authentication methods, in that where the password is not exchanged in plain text over the wire. Each scheme have their own set of helpers and auth_param settings. Notice that helpers for different authentication schemes use different protocols to talk with squid, so they can’t be mixed.
For information on how to set up NTLM authentication see NTLM config examples.
In order to authenticate users, you need to compile and install one of the supplied authentication modules found in the helpers/basic_auth/ directory, one of the others, or supply your own.
You tell Squid which authentication program to use with the auth_param option in squid.conf. You specify the name of the program, plus any command line options if necessary. For example:
auth_param basic program /usr/local/squid/bin/ncsa_auth /usr/local/squid/etc/passwd
How do I use authentication in access controls?
Make sure that your authentication program is installed and working correctly. You can test it by hand.
Add some proxy_auth ACL entries to your squid configuration. For example:
acl foo proxy_auth REQUIRED http_access allow foo http_access deny all
The REQUIRED term means that any authenticated user will match the ACL named foo.
Squid allows you to provide fine-grained controls by specifying individual user names. For example:
acl foo proxy_auth REQUIRED acl bar proxy_auth lisa sarah frank joe acl daytime time 08:00-17:00 http_access allow bar http_access allow foo daytime http_access deny all
In this example, users named lisa, sarah, joe, and frank are allowed to use the proxy at all times. Other users are allowed only during daytime hours.
How do I ask for authentication of an already authenticated user?
If a user is authenticated at the proxy you cannot “log out” and re-authenticate. The user usually has to close and re-open the browser windows to be able to re-login at the proxy. A simple configuration will probably look like this:
acl my_auth proxy_auth REQUIRED http_access allow my_auth http_access deny all
But there is a trick which can force the user to authenticate with a different account in certain situations. This happens if you deny access with an authentication related ACL last in the http_access deny statement. Example configuration:
acl my_auth proxy_auth REQUIRED acl google_users proxyauth user1 user2 user3 acl google dstdomain .google.com http_access deny google !google_users http_access allow my_auth http_access deny all
In this case if the user requests http://www.google.com then first second http_access line matches and triggers re-authentication unless the user is one of the listed users. Remember: it’s always the last ACL on a http_access line that “matches”. If the matching ACL deals with authentication a re-authentication is triggered. If you didn’t want that you would need to switch the order of ACLs so that you get http_access deny !google_users google.
You might also run into an authentication loop if you are not careful. Assume that you use LDAP group lookups and want to deny access based on an LDAP group (e.g. only members of a certain LDAP group are allowed to reach certain web sites). In this case you may trigger re-authentication although you don’t intend to. This config is likely wrong for you:
acl ldapgroup-allowed external LDAP_group PROXY_ALLOWED http_access deny !ldapgroup-allowed http_access allow all
The second http_access line would force the user to re-authenticate time and again if he/she is not member of the PROXY_ALLOWED group. This is perhaps not what you want. You rather wanted to deny access to non-members. So you need to rewrite this http_access line so that an ACL matches that has nothing to do with authentication. This is the correct example:
acl ldapgroup-allowed external LDAP_group PROXY_ALLOWED http_access deny !ldapgroup-allowed all http_access allow all
This way the http_access line still matches. But it’s the all ACL which is now last in the line. Since all is a static ACL (that always matches) and has nothing to do with authentication you will find that the access is just denied.
Send Custom HeadersHeader set P3P "policyref=\"http://www.askapache.com/w3c/p3p.xml\"" Header set X-Pingback "http://www.askapache.com/xmlrpc.php" Header set Content-Language "en-US" Header set Vary "Accept-Encoding"
Blocking based on User-Agent HeaderSetEnvIfNoCase ^User-Agent$ .*(craftbot|download|extract|stripper|sucker|ninja|clshttp|webspider|leacher|collector|grabber|webpictures) HTTP_SAFE_BADBOT SetEnvIfNoCase ^User-Agent$ .*(libwww-perl|aesop_com_spiderman) HTTP_SAFE_BADBOT Deny from env=HTTP_SAFE_BADBOT
proxy_auth acl causing challenge loop
> Well, I really prefer the old behaviour, so I hope the behaviour is not
> hardcoded, but configurable.
It’s not hardcoded, instead it is dependent on how your http_access rules
Squid prompts for login credentials if the user is denied access by an
authentication related acl (proxy_auth, proxyauth_regex, external using
http_access deny someacl authacl
prompts for new credentials if matched (denied by authacl)
http_access deny authacl someacl
does nor prompt for new credentials (denied by someacl)
- smb.conf man page
- smbclient man page
- ntlm_auth man page
- Configuring Squid Proxy To Authenticate With Active Directory
- Samba & Active Directory
- The Linux-PAM System Administrators’ Guide