Authentication Helpers - Revision history

Ledhed: /* Setting up Kerberos */

2013-10-04T00:11:45Z

‎Setting up Kerberos

Ledhed: /* Creating the KeyTabs */

2013-10-03T23:50:03Z

‎Creating the KeyTabs

Ledhed at 17:57, 7 March 2011

2011-03-07T17:57:53Z

Ledhed at 17:01, 7 March 2011

2011-03-07T17:01:19Z

Ledhed at 17:00, 7 March 2011

2011-03-07T17:00:34Z

Ledhed at 16:59, 7 March 2011

2011-03-07T16:59:25Z

Ledhed at 16:57, 7 March 2011

2011-03-07T16:57:56Z

Ledhed at 16:30, 7 March 2011

2011-03-07T16:30:02Z

Ledhed: Created page with '== Kerberos == Squid can authenticate against a Kerberos KDC using the SQUID_KERB_AUTH helper.
This is particularly useful for Single Sign On authentication against Windows A...'

2011-03-07T15:54:34Z

Created page with '== Kerberos == Squid can authenticate against a Kerberos KDC using the SQUID_KERB_AUTH helper. This is particularly useful for Single Sign On authentication against Windows A...'

New page

== Kerberos ==
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. 

== DNS & Hostname ==
On the Windows DNS server create a HOST(A) record that points to the squid server.
For this example we'll call the squid server '' web-proxy.domain.lan '' 

You'll also need to set the hostname of the squid server to match. 
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
Now reboot your FreeBSD box to make the changes take effect.

'''NOTE:''' You're going to be creating a AD account with the same username as the squid servers hostname. 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.

[[Category:Squid]]

@@ Line 82: / Line 82: @@
           kdc = FILE:/var/log/krb5kdc.log
           admin_server = FILE:/var/log/kadmind.log
-Where DC.DOMAIN.LAN is the Windows DNS server.
+Where DC.DOMAIN.LAN is the FQDN of a Windows Domain Controller.
-−
-−
 === KeyTab ===

@@ Line 20: / Line 20: @@
 Now we need to map the AD user account to a Kerberos service principal. This is done from the command line using '' ktpass.exe ''.<br>
 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
+  ktpass -princ SERVICE/FQDN@NT-DNS-REALM-NAME -mapuser <UPN> -pass <PASSWORD> -crypto RC4-HMAC-NT -ptype KRB5_NT_PRINCIPAL -out c:\krb5.keytab
 Example:
-  ktpass -princ HTTP/web-proxy.domain.lan@DOMAIN.LAN -mapuser web-proxy.domain.lan -pass Str0ngP@ssw0rd -crypto RC4-HMAC-NT -ptype KRB5_NT_PRINCIPAL -out c:\krb5.keytab
+  ktpass -princ HTTP/web-proxy.domain.lan@DOMAIN.LAN -mapuser web-proxy.domain.lan@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.<br>
@@ Line 42: / Line 42: @@
 <br>
 Once the .keytab is created it needs to be transferred to the squid server. [http://winscp.net WinSCP] works well for this, but a thumb drive or CD would also work.
 == FreeBSD ==

← Older revision		Revision as of 17:57, 7 March 2011
Line 53:		Line 53:
	You'll also need to change /etc/hosts to match		You'll also need to change /etc/hosts to match
	192.168.99.254 web-proxy.domain.lan web-proxy		192.168.99.254 web-proxy.domain.lan web-proxy
−	~~Now reboot your FreeBSD box to make the changes take effect.~~


		+	=== 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.<br>
		+	If you only have 1 .keytab then move the transferred file (krb5.keytab) to the /etc directory.<br>
		+	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)<br>
		+	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.<br>
		+	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.<br>
		+	http://wiki.squid-cache.org/ConfigExamples/Authenticate/Kerberos <br>
		+
		+	http://www.grolmsnet.de/kerbtut/ <br>
		+	http://msdn.microsoft.com/en-us/library/ms995329 <br>
		+	http://technet.microsoft.com/en-us/library/bb742433.aspx <br>
		+
		+	http://serverfault.com/questions/66556/getting-squid-to-authenticate-with-kerberos-and-windows-2008-2003-7-xp <br>
		+	http://klaubert.wordpress.com/2008/01/09/squid-kerberos-authentication-and-ldap-authorization-in-active-directory/ <br>

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

@@ Line 1: / Line 1: @@
-== Kerberos ==
+Squid can authenticate against a Kerberos KDC using the '''SQUID_KERB_AUTH''' helper.<br>
 Squid can authenticate against a Kerberos KDC using the SQUID_KERB_AUTH helper.<br>
 This is particularly useful for Single Sign On authentication against Windows Active Directory.<br>

@@ Line 18: / Line 18: @@
-== Creating the KeyTabs ==
+=== 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 ''.<br>
 KTPASS Usage:

← Older revision		Revision as of 16:57, 7 March 2011
Line 15:		Line 15:
	On the Windows DNS server create a HOST(A) record that points to the squid server.		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.<br>		As mentioned above the AD Username must match the squid servers FQDN.<br>
		+
		+
		+
		+	== 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 ''.<br>
		+	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/web-proxy.domain.lan@DOMAIN.LAN -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.<br>
		+	Windows 2008 - 2008 R2:
		+	-crypto RC4-HMAC-NT
		+	-ptype KRB5_NT_PRINCIPAL
		+	<br>
		+	Windows 2003 SP1 - 2003 R2:
		+	-crypto RC4-HMAC-NT
		+	-ptype KRB5_NT_SRV_HST
		+	<br>
		+	Windows 2003:
		+	-crypto DES-CBC-MD5
		+	-ptype KRB5_NT_PRINCIPAL
		+	<br>
		+	Windows 2000:
		+	-crypto DES-CBC-MD5
		+
		+	<br>
		+	Once the .keytab is created it needs to be transferred to the squid server. [http://winscp.net WinSCP] works well for this, but a thumb drive or CD would also work.
		+
		+

@@ Line 4: / Line 4: @@
-== DNS & Hostname ==
+== Windows ==
 On the Windows DNS server create a HOST(A) record that points to the squid server.
-For this example we'll call the squid server '' web-proxy.domain.lan ''<br>
+As mentioned above the AD Username must match the squid servers FQDN.<br>
 You'll also need to set the hostname of the squid server to match.<br>
 On FreeBSD you set the hostname in /etc/rc.conf by setting:
   hostname="web-proxy.domain.lan"
@@ Line 15: / Line 25: @@
 Now reboot your FreeBSD box to make the changes take effect.
-'''NOTE:''' You're going to be creating a AD account with the same username as the squid servers hostname. 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.