Authenticating Wi-Fi Users with FreeRADIUS

Businesses can use a good stout RADIUS server to authenticate any network client. Dial-up, DSL, virtual private networks (VPN), wireless networks – you name it, RADIUS will authenticate it. If you’re ready to learn how to set up a FreeRADIUS server to authenticate users for a wireless network, test new configurations safely, and configure a wireless access point and clients to use the new FreeRADIUS server, you’ve come to the right place.

RADIUS stands for Remote Authentication Dial In User Service, and as the name implies it has been around awhile. FreeRADIUS is free software, licensed under the GPL, and free of cost, with commercial support available from Network Radius. FreeRADIUS calls itself “the world’s most popular RADIUS server,” and it is the basis of many commercial RADIUS servers.

A RADIUS server does not talk to users directly, but sits behind a network access server (NAS), such as a wireless access point (WAP). The NAS talks to clients, and hands off the authentication to the RADIUS server. Any number of WAPs and other network gateways can use a single RADIUS server to handle authentication.

FreeRADIUS implements the AAA protocol: authentication, authorization, and accounting. Authentication involves evaluating credentials, such as a login and password, public key, or smart card, to determine whether a user should be allowed to log in to a network. Authorization means access and resource controls, such as what servers or files users are allowed to access, what locations they can log in from, and time-of-day restrictions. Accounting covers logging and analyzing user activities, what network resources users use, and for how long. This article focuses on authentication.

FreeRADIUS runs on pretty much any Linux or Unix operating system, and it works on a wide range of hardware architectures: Itanium, PowerPC, Sparc and Sparc64, x86 and x86_64. For this article I’m using Debian Linux on an old single-core AMD Sempron PC. FreeRADIUS is included in most Linux distributions, so it’s easy to install using your favorite package manager. Source code, binary packages, and installation help are available from the download page.

Most Linux systems, such as Red Hat, CentOS, and Fedora, use radiusd as the standard name for the FreeRADIUS daemon, and raddb as its file directory. By contrast, Debian (and its descendants, such as Ubuntu and Linux Mint) calls the radiusd daemon freeradius, and /etc/raddb is /etc/freeradius.

Get expert CentOS support OpenLogic offers support on more than 500 open source software packages.

We’ll configure FreeRADIUS to use the EAP-TTLS authentication protocol. EAP is Extensible Authentication Protocol; TTLS is Tunneled Transport Layer Security. EAP-TTLS uses strong SSL/TLS encryption on the authentication session, and it’s easy to administer because it requires an SSL certificate only for the server. You have to copy the server certificate to all clients, but this is simpler than authentication protocols that use mutual authentication, such as EAP-TLS, which requires a public key infrastructure (PKI), and creating, distributing, and tracking individual client certificates. Virtually any network client can use EAP-TTLS – Linux, Mac OS X, other Unixes, and Windows. Visit the EAP page of the FreeRADIUS wiki to learn more about the various authentication protocols FreeRADIUS supports.

First Steps

FreeRADIUS is designed to work as installed with minimal changes. The rule is to touch nothing unless you are absolutely certain it’s necessary, because FreeRADIUS configuration files are large and it is easy to make a mess. You should have to edit only three files under /etc/freeradius: users, eap.conf, and clients.conf. Comments in the configuration files serve as documentation. If you want to see just the active configuration options without the comments, and with line numbers, use this egrep command:

# egrep -nv '(#|^\s*$)' /etc/freeradius/users

Debian does some preliminary chores for you when you install it via apt-get install freeradius: It creates the server users and appropriate group memberships, creates symlinks in /etc/freeradius/certs to the default testing SSL server certificates that are included in all FreeRADIUS installations, and starts up the freeradius daemon. FreeRADIUS reads its configurations only once at startup, so before you configure it your first task is to stop the daemon with the command /etc/init.d/freeradius stop.

You can now set up a simple test user, then test the configuration. First create a test user by adding these lines to /etc/freeradius/users:

# test user, remember to delete after testing
testuser Cleartext-Password := "testpassword"

Now start up FreeRADIUS in debugging mode:

# freeradius -X

Press CTRL+c when you want to stop the server. You’ll see a lot of chatter scroll by as FreeRADIUS loads all of its configuration files and modules. This is what you want to see at the end:

Listening on authentication address * port 1812
Listening on accounting address * port 1813
Listening on authentication address 127.0.0.1 port 18120 as server inner-tunnel
Listening on proxy address * port 1814
Ready to process requests.

That means FreeRADIUS is ready to go to work. Now open a second command shell and run this command:

$ radtest testuser testpassword localhost 0 testing123

You’ll see a lot of output whiz by, and if it ends with Access-Accept you have successfully authenticated:

Sending Access-Request of id 11 to 127.0.0.1 port 1812
	User-Name = "testuser"
	User-Password = "testpassword"
	NAS-IP-Address = 127.0.1.1
	NAS-Port = 0
rad_recv: Access-Accept packet from host 127.0.0.1 port 1812, id=11, length=20

This simple test is standard and should work. If you see “Access-Reject” then your configuration has an error. Examine the output from freeradius -X to see what went wrong. Correct your configuration, restart the server, and try again. Once this test succeeds you know that the server is working correctly, and that all major authentication methods work: PAP, CHAP, MS-CHAPv1, MS-CHAPv2, PEAP, EAP-TTLS, EAP-GTC, and EAP-MD5.

Let’s break that radtest command down. These are the required options: radtest username password radius-server nas-port-number secret.

• The username and password are whatever you have set in /etc/freeradius/users.
• radius-server is the server’s hostname, which is configured in clients.conf.
• nas-port-number is 0. Any integer from 0 to 2^31 will work for the port number.
• secret is the shared secret between the NAS and the FreeRADIUS server. testing123 is the default shared secret for testing purposes, as you can see in /etc/freeradius/clients.conf in the “client localhost” stanza.

The testing123 shared secret also appears in several other configuration files; when you’re finished with testing you need to change these, because they are the same in all FreeRADIUS installations, and so they are rather obvious security holes. You can use grep to hunt them down:

# grep -ir testing123 /etc/freeradius

Remote Test

Once the local test succeeds, you can run a simple remote test. Install FreeRADIUS on a second PC, and while that’s installing add this stanza to /etc/freeradius/clients.conf on the FreeRADIUS server:

  client 192.168.2.25 {
      secret = testing123
      shortname = wap-test
   }

Replace the client IP address with the IP address of your second PC, which is standing in for a wireless access point, or any NAS. Restart your FreeRADIUS server, and on the second PC run this command:

$ radtest testuser password 192.168.1.100 1812 testing123

Replace 192.168.1.100 with the IP address of your FreeRADIUS server. Port 1812 is the default UDP port that FreeRADIUS listens on. Again, you should see a happy “Access-Accept” message, meaning all systems are go. You can use hostnames instead of IP addresses, but the FreeRADIUS team recommends using IP addresses on your production server because that is faster and more reliable.

EAP-TTLS Test

One final test could save you hours of annoyance. The eapol_test program is a nifty little tool for testing your EAP configurations and verifying that your user configuration will work before you roll it out to clients.

To get eapol_test, you have to download, unpack, and compile some source code. Building eapol_test from sources is no big deal; just make sure you have the make, gcc, and libssl-dev packages installed beforehand. You can do this on any Linux PC; it doesn’t have to be on your FreeRADIUS server.

Go to http://hostap.epitest.fi/releases/ and download and unpack the latest wpa_supplicant tarball, which at the time of this writing is wpa_supplicant-0.7.3.tar.gz. Then enter the wpa_supplicant-0.7.3/wpa_supplicant directory and run these commands to build an eapol_test binary:

$ cp defconfig .config
$ make eapol_test

When you’ve finished, copy your shiny new eapol_test binary to a bin/ directory on your FreeRADIUS server, such as /usr/local/bin/, and give it a test run as an unprivileged user:

$ eapol_test

This should spit out a list of options, which means it works, and you can configure your test.

When you’re ready to deploy your FreeRADIUS server with real clients you’ll need your own certificate authority (CA) and a new self-signed server certificate, but you don’t need those just yet because FreeRADIUS comes with an example certificate authority and certificates for testing. On Debian, the example CA and server certificates for testing are symlinked in /etc/freeradius/certs: ca.pem, server.key, and server.pem. For non-Debian Linux distros, look in /etc/raddb/certs. After you find yours, edit eap.conf and change one line: change default_eap_type = md5 to default_eap_type = ttls. Then restart FreeRADIUS.

Now you need a configuration file for eapol_test. First copy /etc/freeradius/certs/server.pem to an unprivileged user’s home directory on your server (I used /home/carla), and make sure your user has read permissions to server.pem. Then copy this example eapol-config to the same user’s home directory, making sure that the ca_cert entry is correct for your system. The identity and password are the same ones we’ve already been using.

#eapol-config, for testing EAP on FreeRADIUS

network={
eap=TTLS
eapol_flags=0
key_mgmt=IEEE8021X
identity="testuser"
password="testpassword"
ca_cert="/home/carla/server.pem"
phase2="auth=TTLS"
}

Then run this test command on your FreeRADIUS server:

carla@freeradius:~$ eapol_test -c eapol-config -a 127.0.0.1 -p 1812 -s testing123 -r1

The -c eapol-config option tells which configuration file to reference. -a 127.0.0.1 specifies the IP address of the FreeRADIUS server, -p 1812 is the server’s listening port, -s testing123 is the shared secret, and -r1 means run the test once. The command emits a lot of output, and a successful authentication ends with SUCCESS. If it’s unsuccessful it will tell you why; for example, your shared secret or server key may be wrong. Remember to also examine the debugging output on your FreeRADIUS server.

You can perform a remote test by copying the eapol_test binary, your configuration file, and your server certificate to your second PC. Then run the same command, substituting your FreeRADIUS server’s IP address for the localhost address:

$ eapol_test -c eapol-config -a 192.168.1.100 -p 1812 -s testing123 -r1

When your tests are successful it’s time to do some housecleaning. Comment out all of your test entries in your configuration files, including any you created and all the testing123 entries, delete your test certificates, and create a new set of SSL certificates for your server. Debian users can refer to /usr/share/doc/freeradius/examples/certs/README for instructions and helper scripts. On non-Debian installations look in raddb/certs. The
Certificates page on the FreeRADIUS wiki has more information.

Configuring Users

Now it’s time to make ready for real users to use the new FreeRADIUS server. First, create an entry in clients.conf for your wireless access point, defining your allowed wireless network address range. The shared secret will be copied to the wireless access point that serves this network:

client 192.168.2.0/24 {
        secret          = shouldbeverylongandstrong
        shortname       = wi-fi-1
     }

The shared secret can be up to 31 characters in length, with any combination of upper and lower case letters and numbers. For best security use all 31 characters. Always give each WAP its own unique shared secret, because this identifies it to FreeRADIUS. The shortname is a nickname to help you remember which WAP this is for. Now add your individual users to /etc/freeradius/users. This is the simplest type of entry:

cschroder User-Password := "strongpassword"
          Reply-Message = "Hello, %{User-Name}, you
          have successfully authenticated your login"

You can also configure a default rejection message for invalid logins. Put this in the default section at the end of the users file:

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

Now you must configure your wireless access point to hand off authenticating users to the FreeRADIUS server. Every WAP has its own configuration methods, but usually you need just four bits of information: the IP address of your FreeRADIUS server, the port number (1812), the shared secret, and the type of encryption, which is WPA2/AES.

At this point everything on the server side should be ready to go. To configure Linux, Mac OS X, or Windows clients to use FreeRADIUS authentication, you can use any of those platforms’ graphical network configuration tools. You’ll need the following information:

• Security is WPA2 (enterprise)
• Authentication is TTLS (tunneled TLS)
• Username and password
• Location of the client’s copy of the server’s CA certificate (remember, every client must have its own copy)

wpa_supplicant is a good reliable cross-platform command-line supplicant. A supplicant is any program that makes the authentication request to a RADIUS server. This example configuration, in the file /etc/wpa_supplicant.conf, should work for an EAP-TTLS setup on Linux and Unix-like operating systems:

network={
      ssid="yourssid"
      scan_ssid=1
      key_mgmt=WPA-EAP
      pairwise=CCMP TKIP
      group=CCMP TKIP
      eap=TTLS
      identity="username"
      password="password"
      ca_cert="/etc/certs/ca.pem"
   }

Replace the items in italics with your own information. Then add this line to the configuration for the client’s wireless network interface:

pre-up wpa_supplicant -i wlan0 -c /etc/wpa_supplicant.conf -Bw
post-down killall wpa_supplicant 

Replace wlan0 with the name of their network interface. I’ve had mixed results using wpa_supplicant on Windows; if you’re feeling adventurous, give it a try, but Windows’ native graphical network configurator should do the job just fine.

At this point you have learned how to use EAP-TTLS authentication, how to safely test a server, and how to connect users. To learn more advanced FreeRADIUS tasks, such as how to use its authorization and accounting features, security considerations, more advanced user configurations, and other authentication protocols, visit FreeRADIUS.org, where you can find documentation and mailing lists.

Related posts:

1. A Fast and Secure Web Proxy for Corporate Users
2. Simplify Administration with Directory Services
3. Creating a Secure Repository with Subversion
4. Share Files Easily with ProFTPD
5. Using OpenLDAP for Remote Authentication

Related Open-Source Packages

CentOS:	See all CentOS Articles »	Get CentOS Support at OLEX »
FreeRADIUS:	See all FreeRADIUS Articles »	Get FreeRADIUS Support at OLEX »