Note: The information here is current for version 2.5.
Users will be authenticated if squid is configured to use proxy_auth ACLs (see next question).
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.
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 schemes, although currently you can only use one scheme at a time.
The Squid source code comes with a few authentcation processes for Basic authentication. These include:
In addition Squid also supports the NTLM and Digest authentication schemes which both provide more secure authentication methods where the password is not exchanged in plain text. Each scheme have their own set of helpers and auth_param settings. You can not mix helpers between the different authentication schemes. For information on how to set up NTLM authentication see winbind .
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
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 acl all src 0/0 http_access allow foo http_access deny allThe REQURIED 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 acl all src 0/0 http_access allow bar http_access allow foo daytime http_access deny allIn 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.
Yes. Successful authentication lookups are cached for one hour by default. That means (in the worst case) its possible for someone to keep using your cache up to an hour after he has been removed from the authentication database.
You can control the expiration time with the auth_param option.
Note: This has nothing to do with how often the user needs to re-authenticate himself. It is the browser who maintains the session, and re-authentication is a business between the user and his browser, not the browser and Squid. The browser authenticates on behalf of the user on every request sent to Squid. What this parameter controls is only how often Squid will ask the defined helper if the password is still valid.
Squid stores cleartext passwords in itsmemory cache.
Squid writes cleartext usernames and passwords when talking to the external authentication processes. Note, however, that this interprocess communication occors over TCP connections bound to the loopback interface or private UNIX pipes. Thus, its not possile for processes on other comuters or local users without root privileges to "snoop" on the authentication traffic.
Each authentication program must select its own scheme for persistent storage of passwords and usernames.
Winbind is a recent addition to Samba providing some impressive capabilities for NT based user accounts. From Squid's perspective winbind provides a robust and efficient engine for both basic and NTLM challenge/response authentication against an NT domain controller.
The winbind authenticators have been used successfully under Linux, FreeBSD and Solaris.
Samba-3.X is supported natively using the ntlm_auth helper shipped as part of Samba. No Squid specific winbind helpers need to be compiled (and even if compiled they won't work with Samba-3.X)
Samba-2.2.X is supported using the winbind helpers shipped with Squid, and uses an internal Samba interface to communicate with the winbindd daemon. It is therefore sensitive to any changes the Samba team may make to the interface.
The winbind helpers shipped with Squid-2.5.STABLE2 supports Samba-2.2.6 to Samba-2.2.7a and hopefully later Samba-2.X versions. To use Squid-2.5.STABLE2 with Samba versions 2.2.5 or ealier the new --with-samba-sources=... configure option is required. This may also be the case with Samba-2.2.X versions later than 2.2.7a or if you have applied any winbind related patches to your Samba tree.
Squid-2.5.STABLE1 supported Samba 2.2.4 or 2.2.5 only. Use of Squid-2.5.STABLE2 or later recommended with current Samba-2.X releases.
For Samba-3.X the winbind helpers shipped with Squid should not be used (and won't work if your attempt to do so), instead the ntlm_auth helper shipped as part of the Samba-3 distribution should be used. This helper supports all versions of Squid and both the ntlm and basic authentication schemes. For details on how to use this Samba helper see the Samba documentation. For group membership lookups the wbinfo_group helper shipped with Squid can be used (this is just a wrapper around the samba wbinfo program and works with all versions of Samba)
For full details on how to configure Samba and joining a domain please see the Samba documentation. The Samba team has quite extensive documentation both on how to join a NT domain and how to join a Active Directory tree.
Build/Install Samba-3.X
Samba must be built with these configure options:
--with-winbind
Then follow the Samba installation instructions. But please note that neither nsswitch or the pam modules needs to be installed for Squid to function, these are only needed if you want your OS to integrate with the domain for UNIX accounts.
Build/Install Samba-2.2.X
Samba must be built with these configure options:
--with-winbind
--with-winbind-auth-challenge
Optionally, if building Samba 2.2.5, apply the smbpasswd.diff patch. See SMBD and Machine Trust Accounts below to determine if the patch is worthwhile.
Test Samba's winbindd
workgroup = mydomain password server = myPDC security = domain winbind uid = 10000-20000 winbind gid = 10000-20000 winbind use default domain = yes
# wbinfo -t Secret is good
# wbinfo -a mydomain\\myuser%mypasswd plaintext password authentication succeeded error code was NT_STATUS_OK (0x0) challenge/response password authentication succeeded error code was NT_STATUS_OK (0x0)NOTE: both plaintext and challenge/response should return "succeeded." If there is no "challenge/response" status returned then Samba was not built with "--with-winbind-auth-challenge" and cannot support ntlm authentication.
SMBD and Machine Trust Accounts
Samba 3.x
The Samba team has incorporated functionality to change the machine
trust account password in the new "net" command. A simple daily cron
job scheduling "net rpc changetrustpw" is all that is needed,
if anything at all.
Samba 2.2.x
Samba's smbd daemon, while not strictly required by winbindd may be needed to manage the machine's trust account.
Well behaved domain members change the account password on a regular basis. Windows and Samba servers default to changing this password every seven days.
The Samba component responsible for managing the trust account password is smbd. Smbd needs to receive requests to trigger the password change. If the machine will be used for file and print services, then just running smbd to serve routine requests should keep everything happy.
However, in cases where Squid's winbind helpers are the only reason Samba components are running, smbd may sit idle. Indeed, there may be no other reason to run smbd at all.
There are two sample options to change the trust account. Either may be scheduled daily via a cron job to change the trust password.
UglySolution.pl is a sample perl script to load smbd, connect to a Samba share using smbclient, and generate enough dummy activity to trigger smbd's machine trust account password change code.
smbpasswd.diff is a patch to Samba 2.2.5's smbpasswd utility to allow changing the machine account password at will. It is a minimal patch simply exposing a command line interface to an existing Samba function.
Note: This patch has been included in Samba as of 2.2.6pre2.
Once patched, the smbpasswd syntax to change the password is:
smbpasswd -t DOMAIN -r PDC
winbind privileged pipe permissions (Samba-3.X)
ntlm_auth requires access to the privileged winbind pipe in order to function properly. You enable this access by changing group of the winbind_privileged directory to the group you run Squid as (cache_effective_group setting in squid.conf).
chgrp squid /path/to/winbind_privileged
Build/Install Squid
Samba-3.X
As Samba-3.x has it's own authentication helper there is no need to build any of the Squid authentication helpers for use with Samba-3.x (and the helpers provided by Squid won't work if you do). You do however need to enable support for the ntlm scheme if you plan on using this. Also you may want to use the wbinfo_group helper for group lookups
--enable-auth="ntlm,basic"
--enable-external-acl-helpers="wbinfo_group"
Samba-2.X<
Squid must be built with the configure options:
--enable-auth="ntlm,basic"
--enable-basic-auth-helpers="winbind"
--enable-ntlm-auth-helpers="winbind"
--enable-external-acl-helpers="wb_group"
Test Squid without auth
Before going further, test basic Squid functionality. Make sure squid is functioning without requiring authorization.
Test the Samba-3.x helper
Testing the winbind ntlm helper is not really possible from the command line, but the winbind basic authenticator can be tested like any other basic helper. Make sure to run the test as your cache_effective_user
# /usr/local/bin/ntlm_auth --helper-protocol=squid-2.5-basic
mydomain+myuser mypasswd
OK
The helper should return "OK" if given a valid username/password.
+ is the domain separator set in your smb.conf
Test the Samba-2.2.X helper
Testing the winbind ntlm helper is not really possible from the command line, but the winbind basic authenticator can be tested like any other basic helper:
# /usr/local/squid/libexec/wb_auth -d
/wb_auth[65180](wb_basic_auth.c:136): basic winbindd auth helper ...
mydomain\myuser mypasswd
/wb_auth[65180](wb_basic_auth.c:107): Got 'mydomain\myuser mypasswd' from squid (length: 24).
/wb_auth[65180](wb_basic_auth.c:54): winbindd result: 0
/wb_auth[65180](wb_basic_auth.c:57): sending 'OK' to squid
OK
The helper should return "OK" if given a valid username/password.
Edit squid.conf
Add the following to enable both the winbind basic and ntlm authenticators. IE will use ntlm and everything else basic:
auth_param ntlm program /usr/local/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp
auth_param ntlm children 30
auth_param ntlm max_challenge_reuses 0
auth_param ntlm max_challenge_lifetime 2 minutes
auth_param basic program /usr/local/bin/ntlm_auth --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
Note: If your Samba was installed as a binary package ntlm_auth is probably installed as /usr/bin/ntlm_auth, not /usr/local/bin/ntlm_auth. Adjust the paths above accordingly.
Add the following to enable both the winbind basic and ntlm authenticators. IE will use ntlm and everything else basic:
auth_param ntlm program /usr/local/squid/libexec/wb_ntlmauth
auth_param ntlm children 5
auth_param ntlm max_challenge_reuses 0
auth_param ntlm max_challenge_lifetime 2 minutes
auth_param basic program /usr/local/squid/libexec/wb_auth
auth_param basic children 5
auth_param basic realm Squid proxy-caching web server
auth_param basic credentialsttl 2 hours
Note: For Samba-3.X the Samba ntlm_auth helper is used instead of the wb_ntlmauth and wb_auth helpers above. This helper supports all Squid versions and both ntlm and basic schemes via the --helper-protocol= option. See the Samba documentation for details.
acl AuthorizedUsers proxy_auth REQUIRED
..
http_access allow all AuthorizedUsers
Test Squid with auth
Test browsing through squid with IE. If logged into the domain, a password prompt should NOT pop up.
Confirm the traffic really is being authorized by tailing access.log. The domain\username should be present.
Test with a non-IE browser. A standard password dialog should appear.
Entering the domain should not be required if the user is in the default domain and "winbind use default domain = yes" is set in smb.conf. Otherwise, the username must be entered in "domain+username" format. (where + is the domain separator set in smb.conf)
If no usernames appear in access.log and/or no password dialogs appear in either browser, then the acl/http_access portions of squid.conf are not correct.
Note that when using NTLM authentication, you will see two "TCP_DENIED/407" entries in access.log for every request. This is due to the challenge-response process of NTLM.
References
Joining a Domain in Samba 2.2.x
Authentication is by default disabled in acceleartor mode in Squid-2.X due to conflicts with transparent interception. To enable this feature, at the top of acl.c add the following line:
#define AUTH_ON_ACCELERATION 1
Then "make install".
This feature is somewhat hidden because
The whole concept of "acceleration" in Squid is currently being reworked for the Squid-3.0 release to fix this and a number of other issues.