« Previous 1 2 3 Next »
FreeRADIUS for WiFi hotspots
Large Radius
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.
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].
« Previous 1 2 3 Next »