RADIUS Clients

For FreeRADIUS to allow access, FreeRADIUS must first know the client that wants to authenticate a user. The client configuration is found in the clients.conf file. It contains the network parameters and security settings of the Network Access Server (NAS; for the WiFi hotspot in this example).

The client keyword, followed by a name, starts each client configuration; the configuration itself is enclosed in braces. By default, the only client is localhost. It rejects all connections that do not originate from the same computer. The name can also serve as a definition of allowed clients, such as localhost or 192.168.1.2/32. Since FreeRADIUS Version 2, this setup is no longer required, but it still works. Otherwise, ipaddr and netmask define the permissible network parameters for this client.

A RADIUS server also requires a shared secret from the client – a password that serves as the basis for further encrypted communication. The default localhost client supplies testing123 here. To sum up, the configuration looks like this:

client localhost {
  ipaddr = 127.0.0.1
  secret = testing123
  netmask = 32
}

The optional netmask entry defines the allowed subnet. If it is missing, it is set to 32, which corresponds to exactly one computer. As an alternative to the IP address, the ipaddr entry can also use a hostname. However, this means that if there is a problem with the DNS server, the RADIUS server fails.

The radclient tool included in FreeRADIUS makes it possible to test access at the command line. In the default configuration, the RADIUS server initially only lets you do this locally; Figure 3 shows the output.

Figure 3: The radtest program helps you debug a RADIUS server.

Hints and Huntgroups

Two other configuration files and FreeRADIUS concepts go by the names of huntgroups and hints. Huntgroups are user groups whose members access the same NAS. Accordingly, a simple huntgroups configuration looks like this:

local  NAS-IP-Address == 192.168.1.1

This setting assigns all users authenticated by the RADIUS client (NAS) with the IP address 192.168.1.1 to the local huntgroup. This information can be used in the users file by synchronizing the huntgroup-name attribute with the user group membership. This setup offers the option of creating different entries for a user that are enabled depending on the NAS used, which make sense, in particular, in combination with the DEFAULT user.

Hints allow detailed configuration directly via the username, with the client appending scenario-dependent prefixes or suffixes. The supplied hints file contains settings typical for IPs, which assign the matching protocols to usernames ending in .ppp, .slip, and .cslip. Then, password-based authentication continues with the remainder of the username, as defined by the Strip-User-Name = Yes parameter.

The following entry thus leads to the authentication of a user who logs in as ADMIN.ppp. After the PPP protocol has been allocated, FreeRADIUS authorizes the user as ADMIN.

DEFAULT Suffix == ".ppp", Strip-User-Name = Yes
  Hint = "PPP",
  Service-Type = Framed-User,
  Framed-Protocol = PPP

Again, a combination with DEFAULT is useful.

User Databases

FreeRADIUS also lets you store the user data in sources other than the users file. In addition to modules for various SQL databases, Active Directory Service (ADS) and LDAP are potential candidates.

For MySQL, you can enter the user data in a database with the same attributes and values as described for the users file. The SQL scripts (admin.sql and schema.sql) create users, databases, and schemas in the sql/mysql subdirectory. Matching counterparts are available for PostgreSQL.

You then need to enable the $INCLUDE sql.conf entry in radiusd.conf, which is commented out by default. In sql.conf, the database gives you a choice between mysql, mmsql, oracle, and postgresql. Next, define the server, login, and password for access to the database in the same file.

The MySQL database created here stores the individual user entries in the radcheck table. The fields username, attribute, value, and op can be set, for example, to ADMIN, Cleartext-Password, magazine, and := to create a user with the same properties as used in the users file earlier.

The radreply table defines user-specific response messages, as well as network settings, and usergroup assigns users to groups, and radgroupreply defines group-specific responses  [4].