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?
Use FreeRADIUS together with OpenSSL. There are four steps to this:
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:
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:
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:
DEFAULT Auth-Type := Reject
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
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:
dh_file = /etc/raddb/keys/dh2048.pem
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 theeapline is uncommented:
Then, in the Authentication module, make sure theeap line is uncommented:
Finally, make sure these lines are uncommented and the correct user and group are entered. These vary, so check your own distribution:
user = radiusd
Shut down FreeRADIUS if it is running, then run these commands to test it:
# freeradius -X
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.
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:
This is less secure because it uses the same secret for all access points, but itís easier to manage.
blog comments powered by Disqus