This directive tells FreeRADIUS whether to look up the canonical names of the requesting clients or simply log their IP address and move on. Much like with Apache, DNS queries take a long time and, especially on highly loaded servers, can be a detriment to performance. Turning this option on also causes
radiusd to block the request for 30 seconds while it determines the CNAME associates with that IP address. Only turn this option on if you are sure you need it.
hostname_lookups = [yes/no]
hostname_lookups = no
This directive determines whether FreeRADIUS should dump to core when it encounters an error or simply silently quit with the error. Only enable this option if you're developing for FreeRADIUS or attempting to debug a problem with the code.
allow_core_dumps = [yes/no]
allow_core_dumps = no
regular and extended expressions
This set of controls configures regular and extended expression support. Realistically, you shouldn't need to alter these as they're set when running the ./configure command upon initial install.
regular_expressions = [yes/no]; extended_expressions = [yes/no]
regular_expressions = yes; extended_expressions = yes
These directives control how access to and requests of the FreeRADIUS server are logged. The
log_stripped_names control instructs FreeRADIUS whether to include the full
User-Name attribute as it appeared in the packet. The
log_auth directive specifies whether to log authentication requests or simply carry them out without logging. The
log_auth_badpass control, when set to yes, causes
radiusd to log the bad password that was attempted, while the
log_auth_goodpass logs the password if it's correct.
log_stripped_names = [yes/no]; log_auth = [yes/no]; log_auth_badpass = [yes/no]; log_auth_goodpass = [yes/no]
log_stripped_names = no; log_auth = yes; log_auth_badpass = yes; log_auth_goodpass = no
To eliminate case problems that often plague authentication methods such as RADIUS, the FreeRADIUS developers have included a feature that will attempt to modify the
User-Password attributes to make them all lowercase; this is done either before an authentication request, after a failed authentication request using the values of the attributes as they came, or not at all.
Clearly setting the
lower_user directive to
after makes the most sense: it adds processing time to each request, but unless this particular machine normally carries a high load, the reduced troubleshooting time is worth the extra performance cost. However, a secure password often makes use of a combination of uppercase and lowercase letters, so security dictates leaving the password attribute alone.
lower_user = [before/after/no]; lower_pass = [before/after/no]
lower_user = after; lower_pass = no
Much like the
lower_pass controls, these directives preprocess an
Access-Request packet and ensure that no spaces are included. The available options are the same:
no. Again, the most obvious choice is to set
after to save helpdesk time. Some administrators have a tendency to not allow spaces in passwords; if this is the case, set
before (since there is a system-wide policy against spaces in passwords, testing a request as-is is not required).
nospace_user = [before/after/no]; nospace_password = [before/after/no]
nospace_user = after; nospace_password = before
Configuring the users File
The users file, located at /etc/raddb/users, is the home of all authentication security information for each user configured to access the system. Each user has an individual stanza, or entry. The file has a standard format for each stanza:
The first field is the username for each user, up to 253 characters.
On the same line, the next criteria are a list of required authentication attributes such as protocol type, password, and port number.
Following the first line, each user has a set of defined characteristics that allow FreeRADIUS to provision a service best for that user. These characteristics are indented under the first line and separated into one characteristic per line. For example, you might find a Login-Host entry, a dial-back configuration, or perhaps PPP configuration information.
The users file also comes with a default username of--you guessed it--
DEFAULT, which is generally the catchall configuration. That is to say, if there is no explicit match for a particular user, or perhaps the attribute information for a user is incomplete,
radiusd will configure the session based on the information in the
FreeRADIUS processes this file in the order in which the entries are listed. When information received from the RADIUS client equipment matches an entry in the users file, FreeRADIUS stops processing and sets the service up based on that users file entry. However, you can alter this behavior by setting the
Fall-Through attribute to yes in an entry. When
radiusd encounters a positive fall-through entry, it will continue processing the users file and then select the best match for the particular session. The
DEFAULT user can also have a
Fall-Through attribute, which means you can have multiple
DEFAULT entries for various connection scenarios.
If you don't want to issue a password for each user via their entry in the users file, then simply set
Auth-Type := System on the first line for each user. FreeRADIUS will then query the system password database for the correct password, which saves some administrative headache.
A sample complete entry
The following is a complete entry for the user jhassell, dialing into a NAS server using PPP. Note that (a) there is no
Fall-Through attribute set, so FreeRADIUS will stop processing when it encounters this entry, and (b) no
DEFAULT entry will be used to add attribute information to this connection:
jhassell Auth-Type := System Service-Type = Framed-User, Framed-Protocol = PPP, Framed-IP-Address = 192.168.1.152, Framed-IP-Netmask = 255.255.255.0, Framed-Routing = Broadcast-Listen, Framed-Filter-Id = "20modun", Framed-MTU = 1500, Framed-Compression = Van-Jacobsen-TCP-IP
Next, here's a complete entry for the user Anna Watson. She has a space in her user-name and she also has a password specified in her entry. She also gets a positive fall-through so that she can use some of the
DEFAULT user's attributes with her connection:
"Anna Watson" Auth-Type := Local, User-Password == "yes123" Reply-Message = "Hello, %u" Service-Type = Framed-User, Framed-Routing = Broadcast-Listen, Framed-Filter-Id = "20modun", Fall-Through = Yes