4.8. Enterprise Authentication with a RADIUS Server

Problem

The previous recipe is a slick hack for giving your wireless clients individual keys, but it's still not a proper Public Key Infrastructure (PKI), which is better for larger deployments, and better for security. You have decided it's worth running a standalone RADIUS server for your wireless authentication because it offers more security and more flexibility. You'll be able to use it for all network authentication if you want to, not just wireless, and you can scale up at your own pace. So, how do you use a RADIUS server for wireless authentication?

Solution

Use FreeRADIUS together with OpenSSL. There are four steps to this:

  1. Install and configure the FreeRADIUS server

  2. Create and distribute OpenSSL server and client certificates

  3. Configure your wireless access point

  4. Configure client supplicants

Your WAP becomes a Network Access Server (NAS) because it passes along the job of user authentication to the FreeRADIUS server.

To ensure the least hair loss and lowest blood pressure, use your distribution's package manager to install FreeRADIUS. If you prefer a source installation, refer to the INSTALL document in the source tarball.

This recipe requires a PKI using Extensible Authentication Protocol-Transport Layer Security (EAP-TLS) authentication, which means the server and client must authenticate to each other with X.509 certificates. So, you'll need:

This is the strongest authentication you can use. See Recipe 9.5 to learn how to do this the easy way, with OpenVPN's excellent helper scripts. If you don't have OpenVPN, you can get the scripts from OpenVPN.net (http://openvpn.net/).

There are two things you will do differently. First, use password-protected client certificates:

	# ./build-key-pass [client hostname]

And, you will have to create PK12 certificates for Windows clients:

	# ./build-key-pkcs12 [client hostname]

In this recipe, the certificate authority, private server key, and public server key are kept in /etc/raddb/keys. This directory should be mode 0750, and owned by root and the FreeRADIUS group created by your Linux distribution. On Debian, this is root: freerad. On Fedora, root:radiusd. You'll be editing these FreeRADIUS files:

/etc/raddb/clients.conf
/etc/raddb/users
/etc/raddb/eap.conf
/etc/raddb/radiusd.conf

Debian users, look in /etc/freeradius instead of /etc/raddb.

First, tell FreeRADIUS about your wireless access point or points in clients.conf, using one section per WAP. You can start over with a clean new file instead of adding to the default file:

	##/etc/raddb/clients.conf
	client 192.168.1.50 {
	        secret = superstrongpassword
	        shortname = wap1
	        nastype = other
	        }

Then, make a list of authorized users' login names in the users file, and a nice reject message for users who are not in this file. The usernames are the Common Names on their client certificates. Add them to the existing users file:

	##/etc/raddb/users
	"alrac sysadmin" Auth-Type := EAP
	"terry rockstar" Auth-Type := EAP
	"pinball wizard" Auth-Type := EAP

	DEFAULT Auth-Type := Reject
	        Reply-Message = "I hear you knocking, but you can't come in"

Now, create two files containing random data, which EAP needs to do its job. These must be owned by root and the FreeRADIUS group, and readable only to the file owners:

	# openssl dhparam -check -text -5 512 -out /etc/raddb/dh
	# dd if=/dev/random of=/etc/raddb/random count=1 bs=128
	# chown root:radiusd /etc/raddb/dh
	# chown root:radiusd /etc/raddb/random
	# chmod 0640 /etc/raddb/dh
	# chmod 0640 /etc/raddb/random

Make sure you use the correct RADIUS group for your distribution.

eap.conf is where you configure the EAP module. Find and edit these lines in your existing file, using your own filenames:

	##/etc/raddb/eap.conf
	default_eap_type = tls
	tls {
	     private_key_password = [your password]
	     private_key_file = /etc/raddb/keys/xena.crt
	     certificate_file = /etc/raddb/keys/xena.key
	     CA_file = /etc/raddb/keys/ca.crt

	     dh_file = /etc/raddb/keys/dh2048.pem
	     random_file = /etc/raddb/keys/random
	     fragment_size = 1024
	     include_length = yes
	}

radiusd.conf is huge and replete with helpful comments, so I will show just the bits you may need to change. In the Authorization module, make sure the eap line is uncommented:

	##/etc/raddb/radiusd.conf
	# Authorization. First preprocess (hints and huntgroups files),
	authorize {
	...
	eap
	...
	}

Then, in the Authentication module, make sure the eap line is uncommented:

	# Authentication.
	authenticate {
	...
	eap
	...
	}

Finally, make sure these lines are uncommented and the correct user and group are entered. These vary, so check your own distribution:

	user = radiusd
	group = radiusd

Shut down FreeRADIUS if it is running, then run these commands to test it:

	# freeradius -X
	...
	"Ready to process requests"# radtest test test localhost 0 testing123

The first command starts it in debugging mode. The second command sends it a fake authentication test, which should fail. What you want to see is FreeRADIUS responding to the test. Debugging mode emits reams of useful output, so if there are any errors in your configurations, you'll be able to track them down.

Discussion

The trickiest bit is getting your certificates right, but fortunately, the Easy-RSA scripts make the process easy. A good alternative is the excellent graphical PKI manager TinyCA (http://tinyca.sm-zone.net/).

A slick FreeRADIUS feature is that you don't need to use a Certification Revocation List (CRL), though nothing's stopping you if you want to because revoking a user is as simple as removing them from the users file.

The various Linux distributions handle the FreeRADIUS user and group in different ways. Some use nobody. Debian creates a freerad user and group. It's important to run FreeRADIUS as an unprivileged user, so make sure that the user and group lines in radiusd.conf are configured correctly.

If you have several WAPs, you may control access by subnet instead of individual WAP:

	##/etc/raddb/clients.conf
	client 192.168.0.0/24 {
	   secret = superstrongpassword
	   shortname = wap_herd
	   nastype = other

This is less secure because it uses the same secret for all access points, but it's easier to manage.

See Also