The Squid NTLM Helper Program has options to allow both the previous NTLM scheme and the newer Kerberos-like scheme, and can switch easily to using either one.
However you cannot use Kerberos-like authentication within the NTLM scheme with DansGuardian/Squid. It can work with Squid and the browser so the credentials will be validated, however it cannot be made to work with DansGuardians “Multiple Filter Groups”.
When this option is used, the credentials are so heavily encrypted and abbreviated that there's no way DansGuardian can extract a username. That's why there isn't –and most likely will never be– a Kerberos authplugin for DansGuardian. If the NTLM scheme is satisfactory and is supported, it should generally be used by DansGuardian/Squid. In some cases this won't be possible or desirable though.
Given that Kerberos within the NTLM scheme cannot be used by DansGuardian/Squid, what other options are there for obtaining credentials and verifying them against an Active-Directory-like system?
There are various other Squid helper programs that verify credentials directly against an Active-Directory-like system (no intermediate Samba is needed). These include 'nds_auth' and 'squid_ldap_auth'. They appear to the browser (and also to DansGuardian) to use the BASIC credentials exchange. Once obtained this way, Squid uses the helper program to check the usernamd/password against the AD.Typically the AD is accessed directly via LDAP.
It's theoretically possible in .NET to write a web client program that when asked for BASIC credentials responds with the username/password the user logged in as without asking the user to retype them.
Although it's theoretically possible in IE too, there doesn't seem to be any way in reality to configure Internet Explorer to automatically provide the username/password the user logged in as (other than using the encrypted NTLM mechanism). This would be an important capability if it were possible; the uncertainty of the current author is less than satisfactory. If you have further information, please add it here.
In most cases users will have to retype their username/password one time at the beginning of each web session even though they're already logged on. This appears to the browser to be nothing more than a non-automatic BASIC credentials exchange. As a result, no browser configuration at all is necessary.
The chosen Helper program will appear to Squid as a variety of BASIC authentication, and in some cases will require augmentation by a rather extensive program script. There should be detailed instructions for each helper program and these may differ slightly from one version to another.
Here's a typical Squid configuration:
acl AUTH proxy_auth REQUIRED ... auth_param basic program /usr/lib/squid/nds_auth auth_param basic children 5 auth_param basic realm EFA Internet Access auth_param basic credentialsttl 2 hours auth_param basic casesensitive off ... http_access allow AUTH
The credentials exchange will appear to DandGuardian (as it does to the browser) as a BASIC credentials exchange. So for the auth part it may be that all you need is a line like this in 'dansguardian.conf'.
authplugin = '/etc/dansguardian/authplugins/proxy-basic.conf'
You will also need to do all the other steps of implementing Multiple Filter Groups: filtergroups = N, content added to lists/filtergroupslist, and so forth.
Like all BASIC credential exchanges, the credentials are exchanged in cleartext. Just because these are AD credentials and the AD uses Kerberos-like credentials does not mean the exchange between the browser and DansGuardian/Squid is encrypted in any way.
Usually unencrypted BASIC credential exchanges are no big deal because the credentials aren't very valuable. After all they're only for web usage. And they can be changed or replaced easily.
But in this case the credentials are the same as those used to login to the AD, which depending on the way the rest of the system is set up might be quite valuable. And they might be hard to change or replace.
Depending on how paranoid your management is, even when the risk is only miniscule, sending valuable credentials over the local area network in cleartext may not be acceptable.
The risk of someone being able to eavesdrop on the local area network and gather the passwords that are being communicated in cleartext can be made rather small. Here's how:
- Provide each computer with its own network circuit all the way from the computer to the main network infrastructure. Forbid the use of any network “splitter” devices, especially mini-hubs.
- Keep all local area network infrastructure (i.e. all your hubs) and all gateway servers (especially the DansGuardian/Squid server) in locked rooms which can't be physically accessed by anyone without your knowledge.
- Allow login to the DansGuardian/Squid server only by locally defined (/etc/passwd and /etc/group) users, not by any user defined in AD.
- Severely restrict remote login to the DansGuardian/Squid server. Close down Telnet, RSH, and server FTP altogether; allow SSH only with a public/private key; and don't allow remote login by 'root' from anywhere at all no matter what. (Make all IT personnel always either use `sudo` to perform 'root' operations or use `su -` to become 'root'.)
- Use switched ethernet, as it sends each network packet only to the addressed receiving station rather than to everyone.
- If possible, configure the network infrastructure to “lock” each port to the MAC address of the computer that's supposed to be there. If some other computer attempts to connect temporarily, the network connection will simply appear to be dead. And the “ARP Spoofing” method of hacking switched Ethernet will be foiled.
- If you ever use a network sniffer to diagnose a problem and print any part of the network trace, securely destroy (shred or otherwise) all the hardcopy.