Do you know someone who keeps the WiFi password on a piece of paper under their keyboard? Or somewhere equally as insecure? Sloppy password practices are a nightmare for any admin; controlling access to the company network is impossible with a shared password, even if you have a manageable number of employees.

How do you implement security on a WiFi network without a shared password? One solution is IEEE 802.1X, a standard mechanism for network authentication. For enterprise WiFi hotspots, this login procedure usually goes by the name of WPA Enterprise (Figure 1).

Figure 1: Some hotspots support a user-specific configuration with WPA Enterprise.

In most cases, the user database is not managed by the hotspot itself. Instead, the hotspot queries a RADIUS server on the same network (Figure  2): The central user administration actually takes place on the RADIUS server. If you take on a new employee, you enter their account on the RADIUS server, WiFi access included.

Figure 2: A RADIUS server provides user data to the WiFi hotspot.

The resolution for the acronym RADIUS – Remote Authentication Dial-In User Service – shows that the system was designed for greater tasks than the management of wireless users. It is also used by Internet providers, who rely on RADIUS servers to manage their often very numerous users.

RADIUS implements the AAA concept: authentication, authorization, accounting. The first two components play the main role in defining access controls for a wireless network. During authentication, the RADIUS server checks the username and password; in the scope of authorization, it defines optional access parameters, such as the permitted use period or time. Accounting is primarily about the typical requirements of Internet providers, especially detailed logging of transferred data volumes for statistical analysis and billing.

FreeRADIUS

FreeRADIUS [1] is the most widely used RADIUS server. The free software offers tremendous flexibility thanks to a variety of modules and configuration options. Complete packages are available for Linux, Mac OS X, and BSD variants, as well as Windows [2].

FreeRADIUS developers follow the strategy of delivering the program with a configuration that is generically useful. Adjustments to suit your own environment remain unavoidable, but defaults that are directly usable in many real-world scenarios help admins find their way around the wide range of settings.

RADIUS typically runs as a service on Linux (service freeradius start), or you can use the radiusd or freeradius command, depending on your distribution. The FreeRADIUS server then listens for all requests in the default configuration, using the RADIUS default ports 1812 for authentication and 1813 for accounting, both of which are typically defined in /etc/services. For troubleshooting and testing, it's useful to launch FreeRADIUS with freeradius -X, which outputs all debugging messages.

Other network parameters, as well as local settings for logging, threading, security, and the modules used, are located in the radiusd.conf file below the FreeRADIUS configuration directory, usually /etc/freeradius/ on Linux.

The radiusd.conf file organizes most of the options in listen blocks. Each listen block represents a virtual server instance; the preset contains two of them – one for authentication and one for the accounting server. Use the previously mentioned standard ports and accept connections from all addresses (ipaddr=*). Virtual servers in the FreeRADIUS concept are independent instances. They can be configured individually for each specific RADIUS client.

Users

The supplied FreeRADIUS configuration provides several sample entries for users, which are, however, commented out. The users file is responsible for the user configuration. In the simplest case, you just enter the individual users directly:

ADMIN Cleartext-Password := "magazine"

This entry assigns the property Cleartext-Password with a value of magazine to the ADMIN user. FreeRADIUS reads these entries at startup. Now, when a WiFi end user requests access permission from the hotspot, the RADIUS server compares the password sent by the client with this value and sends the appropriate response. Changes to the user database require a restart of the FreeRADIUS server.

The entire FreeRADIUS configuration directory should be readable only for the dedicated FreeRADIUS account to avoid disclosing the user passwords. If you prefer not to save these passwords in the clear in the users file, the rlm_pap module offers various algorithms that use a cryptographic hash of the password, such as MD5 and SHA-1. You pass in the algorithm used as an option and then generate the hash, for example, with sha1sum for SHA-1:

echo -n "magazine" | sha1sum

This entry in the users file,

ADMIN SHA-Password := "e3d5a52968cef277f476a78124d8e05f1d558953"

replaces the one above.

One After Another

FreeRADIUS parses the entries in users from the top down. When it finds a match, it stops processing unless the Fall-Through = Yes parameter is set. This, like other additional options, is located in the line below the user declaration and is indented with a Tab.

The users file has many additional user options, such as the time at which a user can authenticate (Login-Time). The Reply-Message entry defines a custom response message, for example, explaining a rejection. In all, several hundred options are available that can do such things as propose user-specific network configurations at a hotspot. That said, the RADIUS server does not care whether the hotspot implements them; this is the task of the network access node. The complete list of supported FreeRADIUS attributes is available online  [3].

The DEFAULT entry stands for all usernames and is used to specify general settings. This also means that FreeRADIUS stops processing the users file if it encounters a DEFAULT entry, unless it uses Fall-Through = Yes.