Authentication Helpers

Squid can authenticate against a Kerberos KDC using the SQUID_KERB_AUTH helper.
This is particularly useful for Single Sign On authentication against Windows Active Directory.

Windows

Active Directory Account

Create a user account (which will act like a machine/service account) from Active Directory Users and Computers. This account can be created in any OU. The username for this account must match the hostname of the squid proxy server (which we will be setting in the next step). Windows has a few reserved hostnames, "proxy" is one of them. So while using a hostname like proxy.domain.lan seems logical, windows will complain, so its best to avoid it. The "User Login name" should reflect the FQDN of the squid server. In this example we'll use "web-proxy.domain.lan". The pre-Windows 2000 User logon name is limited to 20 characters, so drop the domain.lan parts and use just "web-proxy" for that username.

DNS & Hostname

On the Windows DNS server create a HOST(A) record that points to the squid server. As mentioned above the AD Username must match the squid servers FQDN.

Creating the KeyTabs

Now we need to map the AD user account to a Kerberos service principal. This is done from the command line using ktpass.exe .
KTPASS Usage:

ktpass -princ SERVICE/FQDN@NT-DNS-REALM-NAME -mapuser <USERNAME> -pass <PASSWORD> -crypto RC4-HMAC-NT -ptype KRB5_NT_PRINCIPAL -out c:\krb5.keytab

Example:

ktpass -princ HTTP/[email protected] -mapuser web-proxy.domain.lan -pass Str0ngP@ssw0rd -crypto RC4-HMAC-NT -ptype KRB5_NT_PRINCIPAL -out c:\krb5.keytab

Note: The '-crypto' and '-ptype' vary depending on what version of Windows Server you're running.
Windows 2008 - 2008 R2:

-crypto RC4-HMAC-NT
-ptype KRB5_NT_PRINCIPAL

Windows 2003 SP1 - 2003 R2:

-crypto RC4-HMAC-NT
-ptype KRB5_NT_SRV_HST

Windows 2003:

-crypto DES-CBC-MD5
-ptype KRB5_NT_PRINCIPAL

Windows 2000:

-crypto DES-CBC-MD5

Once the .keytab is created it needs to be transferred to the squid server. WinSCP works well for this, but a thumb drive or CD would also work.

FreeBSD

Setting the Hostname

You'll also need to set the hostname of the squid server to match the DNS record you just created.
On FreeBSD you set the hostname in /etc/rc.conf by setting:

hostname="web-proxy.domain.lan"

You'll also need to change /etc/hosts to match

192.168.99.254           web-proxy.domain.lan  web-proxy

DNS

You'll also need to add the windows DNS server to /etc/resolv.conf

domain      domain.lan
nameserver  192.168.99.1

Setting up Kerberos

You need to configure kerberos to talk to your Windowds AD Domain Controller. This is done by editing /etc/krb5.conf

[libdefaults]
        default_realm = DOMAIN.LAN
        dns_lookup_realm = true
        dns_lookup_kdc = true
        clockskew = 300

[realms]
        DOMAIN.LAN = {
        kdc = DC.DOMAIN.LAN
        default_domain = DOAMIN.LAN
        kpasswd_server = DC.DOMAIN.LAN
        }

[domain_realm]
        .DOMAIN.LAN = DOAMIN.LAN

[logging]
        default = FILE:/var/log/krb5libs.log
        kdc = FILE:/var/log/krb5kdc.log
        admin_server = FILE:/var/log/kadmind.log

Where DC.DOMAIN.LAN is the Windows DNS server.

KeyTab

SQUID_KERB_AUTH looks to /etc/krb5.keytab by default for kerberos keys.
If you only have 1 .keytab then move the transferred file (krb5.keytab) to the /etc directory.
Otherwise you'll need to use ktutil to merge it with your other keytabs.

Testing

Once you've got Kerberos setup and the KeyTab moved to the right place you can begin testing. This can be done with the 'kinit' command.

kinit administrator

This should prompt you for the Windows Administrator password. If entered successfully then you will be returned to the command prompt (other wise you will get an error)
Now check the kerberos tickets.

klist

This should return the kerberos ticket for the Windows Administrator account. If a ticket was created then we can move on to testing the keytab and service principal we created on the Windows server.

kinit -k -t /etc/krb5.keytab HTTP/web-proxy.domain.lan

If everything is working as it should then you should be returned to the command prompt without error.
What the .keytab does is allows the squid server to make queries to the windows server without a human being entering a password. You can now check the ticket with 'klist' again.

Squid

Authentication

Add the follow lines to /usr/local/squid/squid.conf

auth_param negotiate program /usr/local/libexec/squid/squid_kerb_auth -d -s HTTP/web-proxy.domain.lan
auth_param negotiate children 10
auth_param negotiate keep_alive on
acl AUTHENTICATED proxy_auth REQUIRED

http_access allow AUTHENTICATED

Save and reload the squid service:

service squid reload

Testing

The easiest way to test is to snoop /var/log/squid/access.log for usernames. The cache.log will also show the usefull info for troubleshooting purposes.

Web Browser Proxy Settings

When you configure your proxy settings in the web browser, you need to use the FQDN of the squid server. IP Addresses will not work.! Address:

web-proxy.domain.lan

Port:

3128

(3128 is squids default listen port, 8080 is another common port. This can be checked against squid.conf).

References

I couldn't have done this without help from the following sites.
http://wiki.squid-cache.org/ConfigExamples/Authenticate/Kerberos

http://www.grolmsnet.de/kerbtut/
http://msdn.microsoft.com/en-us/library/ms995329
http://technet.microsoft.com/en-us/library/bb742433.aspx

http://serverfault.com/questions/66556/getting-squid-to-authenticate-with-kerberos-and-windows-2008-2003-7-xp
http://klaubert.wordpress.com/2008/01/09/squid-kerberos-authentication-and-ldap-authorization-in-active-directory/