FreeRADIUS InkBridge

Server Configuration

Why does PAP authentication work but CHAP fails?

You’re not using plaintext passwords in the raddb/users file or other password store. The CHAP protocol requires a plaintext password on the radius server side, for PAP it doesn’t matter.

To use CHAP, each user entry must shown in this format:

'Auth-Type = Local, Password = "stealme"'

If only PAP is used, format your entries as:

'Auth-Type = System'

Why do I see only one radiusd in the process list?

If FreeRADIUS is configured to use threads, then nothing is wrong. Newer Linux kernels / procps utilities report one thread by default. To view all threads, execute ps command with one of the following options:

Old ps version / kernel (2.4):

  • ps -efm

  • ps auxm

New ps version / kernel (2.6):

  • ps -efl

  • ps auxH

I can’t get RADIUS to pick up changes in the raddb/users.

The server reads the config files once at startup. This is very efficient, but you need to tell the server somehow to re-read its config files after you made a change. This can be done by sending the server a SIGHUP (signal '1' on almost if not all UNIX systems). The server writes its PID in /var/run/radiusd.pid, so a simple UNIX command to do this would be:

kill -1 `cat /var/run/radiusd.pid`

Some people are tempted to do this every 5 minutes so that changes come through automatically. That is not a good idea it takes some time to re-read the config files and the server may drop a few authentication requests at that time. A better idea is to use a so-called "timestamp file" and only send a SIGHUP if the raddb/users file changed since the last time. See the example SIGHUP script.

SIGHUP script 
#! /bin/sh
cd /etc/raddb
if [ ! -e .last-reload ] || [ "`find users -nt .last-reload`" ]; then
	if radiusd -C > .last-reload 2>&1; then
		kill -1 `cat /var/run/radiusd.pid`
	else
		mail -s "radius reload failed!" root < .last-reload
	fi
fi
touch .last-reload

A Makefile is can fulfill this requirement and have raddb checked every 5 minutes.

Can I check the configuration before sending a HUP to the server?

Yes. You check certain parts of the configuration files by using the radiusd -C option. See the radiusd(8) for more details. The server can then be signalled via a HUP signal to re-read the updated configuration files.

Some administrators have automated scripts to update the radius servers configuration files. The problem with this approach is that any syntax errors in the configuration file may cause your main radius server to die. See [Broken Configuration Example]. Therefore there should be some process of checking the configuration files prior to re-starting the server.

Working Configuration 
shell# freeradius -XC; echo $?
FreeRADIUS Version 2.0.0-beta, for host i486-pc-linux-gnu, built on Nov 12 2007 at 17:25:45
[...]
Configuration appears OK.
0
Broken Configuration 
shell# freeradius -XC; echo $?
FreeRADIUS Version 2.0.0-beta, for host i486-pc-linux-gnu, built on Nov 12 2007 at 17:25:45
[...]
/etc/freeradius/users[5]: Syntax error: Previous line is missing a trailing comma for entry DEFAULT
Errors reading /etc/freeradius/users
/etc/freeradius/radiusd.conf[1033]: Instantiation failed for module "files"
[...]
Errors initializing modules
1

Do I need the commas in the raddb/users file?

Yes. Commas link lists of attributes together and must be present for the data to be parsed properly. The general format for a raddb/users file entry is:

name Check-Item = Value, ..., Check-Item = Value
	Reply-Item = Value,
	.
	.
	.
	Reply-Item = Value

The dots represents a repetition of attributes.

  • The first line contains Check-Items only.

  • Commas go between Check-Items.

  • The first line ends without a comma.

  • The next number of lines are Reply-Items only.

  • Commas go between Reply-Items.

  • The last line of the reply-item list ends without a comma.

Check-Items are used to match attributes in a request packet or to set server parameters. Reply-Items are used to set attributes which are to go in the reply packet. So things like Simultaneous-Use go on the first line of a raddb/users file entry and Framed-IP-Address goes on any following line.

Why are all the Incoming Authentication-Request passwords corrupt?

The shared secret is incorrect. This is a text string which is a "secret" (in the raddb/clients file) shared by both the NAS and the server. It is used to authenticate and to encrypt/decrypt packets.

Run the server in debugging mode:

radiusd -X

The first password you see will be in a RADIUS attribute:

Password = "dsa2\2223jdfjs"'

The second password will be in a log message, e.g.:

Login failed [user/password] ...

If the text after the slash is corrupted, then the shared secret is wrong. Delete it on both the NAS and the raddb/clients file and re-enter it. Don’t check to see if they are the same, as there may be hidden spaces or other characters.

Another cause of corrupted passwords being logged is the secret being too long. Certain NAS boxes have limitations on the length of the secret and don’t complain about it. FreeRADIUS is limited to 31 characters for the shared secret.

VSA in Access-Reject

FreeRADIUS is not including VSA attributes in Access-Reject packets. (but it worked in earlier versions of FreeRADIUS). According RFC 2865 (section 5.44) Vendor-Specific Attributes aren’t allow in Access-Reject packets. This issue has been resolved in newer versions of FreeRADIUS.

The NAS ignores the RADIUS server’s reply.

You see lots of duplicate requests in the radius.log, yet users can not login, and/or you are seeing duplicated accounting messages (up to 50 times the same accounting record as if the NAS doesn’t realize you received the packet).

Perhaps your server has multiple IP addresses, perhaps even multiple network cards. If a request comes in on IP address a.b.c.d but the server replies with as source IP address w.x.y.z most NAS won’t accept the answer.

The simplest solution is to have radiusd bind to a specific address. It will only listen to that address and replies will always go out with that address as the source address.

There are several ways to bind to a specific address.

  • The deprecated way is to specify an IP address with the _-i {IP} command-line option.

  • The recommended way is to use the listen directive in radiusd.conf. Multiple listen directives can be added to this file. listen { ipaddr = 192.168.1.250 port = 1817 type = auth }

  • The third way bind_address = 192.168.1.250 port = 1817

The above solution is not always possible. If you have multiple IPs and want FreeRADIUS to listen on all of them, make sure that ./configure --with-udpfromto is specified during compilation. On Linux and FreeBSD systems, this will make FreeRADIUS server respond from the IP the initial request was received on.

I’m having problems running FreeRADIUS under daemontools control.

Daemontools must be installed, configured, and running on your system.

Ensure the following items are configured:

  • The log account and group name such as log.log. Logging programs run under the account.group. Create this account.group pair if it doesn’t exist.

  • Provision the radiusd local service directory with the steps shown below. This is where radiusd stores logs and select configuration files.

Complete the following steps in the /etc/radiusd directory 
groupadd log
useradd -g log log
mkdir /etc/radiusd
mkdir /etc/radiusd/log
mkdir /etc/radiusd/log/main
chmod +t+s /etc/radiusd /etc/radiusd/log
chown log.log /etc/radiusd/log/main

The supervise program starts radiusd by executing a shell script called "run" from /etc/radiusd. Complete the next steps in /etc/radiusd directory.

shell# cd /etc/radiusd
shell# cat run
#!/bin/sh
exec 2>&1
exec /usr/sbin/radiusd -fyz -lstderr

The -f and -l stderr options must be added to the radiusd argument list or svc and logging functions won’t work properly.

The logging feature is also started by a "run" script located in /etc/radiusd/log. The contents of /etc/radiusd/log/run are:

shell# cd /etc/radiusd/log
shell# cat run
#!/bin/sh
exec setuidgid log multilog t ./main

Set the service to start by entering the command:

ln -sf /etc/radiusd /service

Issue signals to radiusd using the svc program as shown by the examples below.

Desired Result Signal Command

To hang-up (HUP) or restart the service and reload the config

svc -h /service/radiusd

To temporarly disable or down the server

svc -d /service/radiusd

To reenable or bring the service back online

svc -u /service/radiusd

The server "Could not link …​ file not found", what do I do?

The 'make' process PRINTS out error messages when it’s creating a static library which links to a dynamic one. If your linker is misconfigured (see #1), then FreeRADIUS still won’t work. Review the error/warning messages produced during the 'make' stage. You may see an error message like the one below, when you try to run the server:

Module: Loaded SQL
rlm_sql: Could not link driver rlm_sql_mysql: file not found
rlm_sql: Make sure it (and all its dependent libraries!) are in the search path of your system's ld.
radiusd.conf[50]: sql: Module instantiation failed.

There are only a few things that can be happening:

  • The mysql_config cannot be found in $PATH. Try running ./configure | grep mysql_config and see if you get the following:

    checking for mysql_config... no
configure: WARNING: mysql libraries not found. Use --with-mysql-lib-dir=<path>.
configure: WARNING: sql submodule 'mysql' disabled

If it is, simply do something like "export $PATH=$PATH:/usr/local/mysql/bin" and "./configure | grep mysql_config" again to make sure you get:

checking for mysql_config... yes

Execute make again by entering the command run "make;make install" from your shell.

  • The shared libraries are stored in a place where your linker can’t find them.

  • The FreeRADIUS server displays an error message received from the linker. You don’t have static libraries for SQL clients on your system. So doing ./configure --disable-shared;make doesn’t help.

The libtool still does dynamic linking when told to do static linking, instead of failing to do the build. It should be taken out and shot.

No changes are required on FreeRADIUS to fix issues with non-FreeRADIUS shared libraries. Fix your SQL libraries by one of the following methods:

  • Save the libraries in a place where the linker can find them.

  • There are static versions of those libraries available.

Use the LD_LIBRARY_PATH environment variable in a script which starts the server, to set the paths where these libraries may be found.

One some systems, you can edit /etc/ld.so.conf, ('man ld.so', or 'man ldconfig'), and add the directory containing the dynamic libraries to that list.

See also the 'libdir' configuration directive in the 'radiusd.conf' file which is distributed with the server. It contains additional information.

If none of these solutions work, then your only option is to build FreeRADIUS without dynamic libraries. This may be done via:

./configure --disable-shared
make
make install

READ the messages produced during the 'make' and 'make install' stages. While there is a lot of text to wade through, these messages may be the only source of information as to what’s wrong your system.