The FreeRADIUS Server is a daemon for unix and unix like operating systems which allows one to set up a radius protocol server, which can be used for Authentication and Accounting various types of network access. To use the server, you also need a correctly setup client which will talk to it, including terminal servers, Ethernet Switches, Wireless Access Points or a PC with appropriate software which emulates it (PortSlave, radiusclient etc).

FreeRADIUS is being developed by a group of people who call themselves "the FreeRADIUS project".

First of all, FreeRADIUS is an open-source product, and has all the benefits open-source provides.

Also, it has many features not found in free servers and many commercial ones, like:

FreeRADIUS runs on a large number of 32 and 64bit Unix-like platforms.

Yes, the FreeRADIUS Server site is at http://www.freeradius.org/

It contains the server, documentation, and additional RADIUS programs.

Yes, there are mailing lists for announcements, users and developers, they can all be subscribed to freely, and they all have web archives.

Please see the description of FreeRADIUS mailing lists.

You can find it, along with some useful links and documentation, at the official FreeRADIUS WWW site:

Sources are available at:

Please see the list of available packages.

You may also easily build a package from source.

See the instructions on how to build FreeRADIUS.

Yes - there are several ways to accomplish this.

You may specify multiple listen directives.

Note!

If you have a multi-homed server and specify an explicit address to bind to. It may happen that the server does not respond with the right source ip address. Thus the client will likely ignore the server’s response. On Linux and FreeBSD you can solve this by specifying ./configure --with-udpfromto during compilation.

Then the server will always respond with the correct address.

Yes, you can. Assuming you already have daemontools installed, configured and running in your system (see http://cr.yp.to/daemontools.html), you will have to make two decisions: 1. The log account and group name (log.log is used in this example). Logging programs run under this account.group. If this account.group pair does not exist yet, create it now.

Then perform these steps:

The supervise program starts radiusd by running a shell script called "run" from /etc/radiusd. Here are the contents of /etc/radiusd/run:

It is important to add -f and -l stderr to argument list of radiusd or svc and logging functions will not work properly.

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

To set the service to start, issue the following command:

Now you can send signals to radiusd using the svc program. Here are some interesting ones:

To hang-up (HUP) it, reloading the config, do:

To temporarly disable it (down) do:

To reenable it (up) do:

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:

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

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

If the text AFTER the slash is garbage then the shared secret is wrong. Delete it on BOTH the NAS and the raddb/clients file and re-enter it. Do NOT check to see if they are the same, as there may be hidden spaces or other characters.

Another cause of garbage 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.

There are two possible causes of this problem.

Firstly, modify the radacct table schema to be able to store 64bit integers (or 19 digit numeric fields on databases not supporting BIGINT) in the AcctInputOctets and AcctOutputOctets columns using the ALTER TABLE command:

Secondly, modify the accounting queries in sql.conf to make the SQL database perform the computation that is required to merge the two values sent as attributes by the into one single 64-bit integer stored in the database.

All occurences of '%{Acct-Input-Octets}' need to be replaced with:

The same thing needs to be done for '%{Acct-Output-Octets}':

Symptom: you are seeing lots of duplicate requests in 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. See Is there a way to bind FreeRADIUS to a specific IP address? there a way to bind FreeRADIUS to a specific IP address?

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 was specified during compilation (see Is there a way to bind FreeRADIUS to a specific IP address? there a way to bind FreeRADIUS to a specific IP address?). On Linux and FreeBSD this will make FreeRADIUS to respond from the IP the initial request was received to.

Symptom: 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 behaviour was fixed in newer versions of FreeRADIUS

The RADIUS server receives information about user sessions from your NAS but does not actually actively maintain the users sessions. This means that you have to signal your NAS to disconnect sessions.

Depending on your NAS type and it’s configuration there are a number of ways to disconnect sessions.

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.

So, if you’re using CHAP, for each user entry you must use:

If you’re using only PAP, you can get away with:

or anything else that tickles your fancy.

Commas link lists of attributes together. The general format for a raddb/users file entry is:

Where the dots means repetition of attributes.

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.

All the attribute operators :=,==,+= and their meanings are listed in man 5 users on machines that have FreeRADIUS installed and at the page in the wiki.

I’m using a 3Com/USR HiPerArc and I keep getting this message on radius.log:

What should I do to get rid of these messages?

You are using HiPer ARC 4.1.11, right? Version 4.1.11 has a problem reporting NAS-port numbers to Radius. Upgrade the firmware from http://totalservice.usr.com to at least 4.1.59. If you are in Europe you can telephone to 3Com Global Response Center (phone number: 800 879489), and tell them that you have bought it in the last 90 days. They will help you, step by step, to do the upgrade.

Here is a check list:

The radius server calls the checkrad script when it thinks the user is already logged on on one or more other ports/terminal servers to verify that the user is indeed still online on that other port/server. If Simultaneous-Use > 1, then it might be that checkrad is called several times to verify each existing session.

This method successfully prevents a user from logging in multiple times across multiple NAS boxes.

Ascend decided to have the 4000 series NAS boxes retrieve much of their configuration from the RADIUS server. To disable this "feature", set:

This is generally caused by an incorrect named configuration. Check your named files and look for invalid entries.

Another file to investigate is raddb/naslist. All entries there must be resolved by a DNS query.

See question 4.9

The most common problem with PEAP is that the client sends a series of Access-Request messages, the server sends an series of Access-Challenge responses, and then…​ nothing happens. After a little wait, it all starts again.

If you see this happening STOP!

The RADIUS server certificate has to have special OID’s in it, or else the Microsoft clients will silently fail. See the "scripts/xpextensions" file in the server "tar" file for examples, and the following page on Microsoft’s site:

http://support.microsoft.com/kb/814394/en-us

If the clients are running Windows XP SP2, see also:

http://support.microsoft.com/kb/885453/en-us

You MUST follow the instructions on the first page, and install the hot fix from the second page for PEAP or EAP-TLS to work with a Windows machine.

Stop right there. Before going any further, be sure that you have included the following items in your request for help:

Too many people post questions saying "something’s wrong, how do I fix it?" with NO background information. This is worse than useless, it’s annoying.

Now that you have prepared all the information, post your question to the freeradius-users mailing list(http://lists.freeradius.org/mailman/listinfo/freeradius-users)

If you’re REALLY interested in knowing how to debug the RADIUS server yourself, then the following steps will help you:

After upgrading to FreeRADIUS, you may discover that some users are unable to fully use the network, but it worked fine with the previous RADIUS server you were using.

The NAS has no idea which RADIUS server you use, and it doesn’t care. The entire problem is that the responses to the NAS from the servers are different. Since FreeRADIUS only sends the attributes in a response that you tell it to send, the conclusion is that your local configuration of FreeRADIUS is incomplete.

Use 'tcpdump' http://www.tcpdump.org to snoop the RADIUS responses from each server. Once you discover which attributes are missing from the response of FreeRADIUS, you can add them to it’s configuration. Re-start the server, and your users should have full access to the network again.

You may see an error message like the one below, when you try to run the server:

There are only a few things that can be happening:

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

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:

Then you should run "make;make install" again.

2) You put shared libraries into a place where your linker cannot find them.

Everyone blames FreeRADIUS because it’s the one printing the error message. But it just gets the error message from your linker.

3) You don’t have static libraries for SQL clients on your system. So doing ./configure --disable-shared;make doesn’t help.

The 'make' process WILL print out error messages saying 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.

So you probably ignored the error/warning messages produced during the 'make' stage. That’s bad.

And 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.

There is nothing you can do to FreeRADIUS to fix issues with non-FreeRADIUS shared libraries. Fix your SQL libraries so that:

a) your linker can find them

or

b) There are static versions of those libraries available.

You can 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:

Please 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.

If you have configured to use threads, then nothing is wrong. Newer Linux kernels / procps utilities report one thread by default. You can execute ps in the following ways to see all threads:

For older versions of ps / kernel (2.4), use:

For newer versions of ps / kernel (2.6+), you may prefer to use:

On Windows, the short answer is that you don’t.

RADIUS defines a Reply-Message attribute, which you can often use to send text messages in a RADIUS reply packet. PPP has provisions for passing text messages back to the user.

Unfortunately, Microsoft decided to ignore that part of the PPP protocol. So you CAN send messages to Windows PPP users. But Windows will throw the message away, and never show it to the user.

If you don’t like this behaviour, call Microsoft and complain.

On the Mac side, the only dialer that shows up the server’s message is FreePPP at http://www.rockstar.com.

You need to use the Group check item to match a group. You also need to use the Auth-Type := Reject check item to deny them access. A short message explaining why they were rejected wouldn’t hurt, so a Reply-Message reply attribute would be nice. This rule needs to match for all users, so it should be a DEFAULT entry. You want to apply it instead of any other authentication type, so it should be listed BEFORE any other entry which contains an Auth-Type. It doesn’t need a Fall-Through, because you’re not giving the user any permission to do anything, you’re just rejecting them.

The following entry denies access to one specific user. Note that it MUST be put before ANY other entry with an Auth-Type attribute.

The following entry denies access to a group of users. The same restrictions as above on location in the raddb/users file also apply:

You may run a SQL query each time a user has an access denied. First you need to write your SQL statement in the directive postauth_query of the module rlm_sql. For example:

Then add the sql module to the post-auth section of radiusd.conf. Since we want to run the SQL query only on failed login, we need to use the sub-section Post-Auth-Type REJECT. For example:

Note: This option is usable if you want to detect fraud or similar activities from your users. Keep in mind that this table can become very large in case you disable too many user accounts, in case of ddos attack, etc. Every rejected attempt will be logged.

Limit logons between 08:00am and 08:00pm for Unix group "daysonly"

or

Limit logons between 08:00am and 08:00pm, from Monday to Friday for Unix group "weekdays"

Limit logons between 08:00am and 08:00pm, in Saturday and Sunday for Unix group "weekends"

You can’t. A RADIUS server will only log the messages which a NAS sends to it. If your NAS is not sending those messages or attributes, then the RADIUS server will not log them.

You must configure your NAS to send the information you want to the RADIUS server. Once the NAS is sending the information, the server can then log it.

Edit raddb/users, on top of it put

That will accept everybody. If you want this to apply to a single user replace DEFAULT with username. You can also add Auth-Type Accept to radcheck or radgroupcheck entries in order to accept that user/group. This only works for PAP, and does NOT work for EAP-TLS, CHAP, MSCHAP, or WIMAX authentication.

Q: I need to limit some users to be able only to use our POP3 and SMTP server.

The most common approach is to just assign non-globally-routable IP addresses to those users, such as RFC1918 addresses. Depending on your internal network configuration, you may need to set up internal routes for those addresses, and if you don’t want them to do anything besides SMTP and POP3 within your network, you’ll have to set up ACLs on your dialup interfaces allowing only ports 25 and 110 through.

Make sure you have RADIUS authorization enabled on your NAS.

Example user entry in raddb/users file:

CISCO’s config must have:

The access list 160 gets applied on inbound packets and 161 on outbound packets.

You’ll need the redhat/radiusd.pam file from the distribution. It should go into a new file, /etc/pam.d/radiusd.

If you have 100’s to 1000’s of users in /etc/passwd, you’ll want to replace the pam_pwdb.so entries with pam_unix_auth.so, pam_unix_acct.so etc. The pam_pwdb module is INCREDIBLY SLOW for authenticating users from a large /etc/passwd file.

Bruno Lopes F. Cabral|mailto:bruno-at-openline-dot-com-dot-br also says:

Now I can emulate group behaviour using just PAM and some tricks, like

and

this way I have NO users on /etc/password and NO need for lots of lines on /etc/raddb/users. time to search for a db enabled pam_listfile module

The server reads the config files just 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:

Some people would be tempted to do this every 5 minutes so that changes come through automatically. That is not a good idea as it might take 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. For example a script like this, to be run every 5 minutes:

Of course a Makefile is suited perfectly for this kind of stuff.

Some administrators have automated scripts to update the radius servers configuration files. The server can then be signalled via a HUP signal to re-read certain configuration files (see below).

The problem with this approach is that any syntax errors in the configuration file may cause your main radius server to die. Therefore there should be some process of checking the configuration files prior to re-starting the server.

With FreeRADIUS 2.0.0 and up you can use the -C option for radiusd to check certain parts of your configuration files. See the radiusd(8) manpage for further details and limitations of the -C option. Related posts on freeradius-users: 067362(http://lists.freeradius.org/pipermail/freeradius-users/2007-November/067362.html) 067279(http://lists.freeradius.org/pipermail/freeradius-users/2007-November/067279.html)

Use the following configuration :

Which gives : (tcpdump output)

The whole netmask business is a complicated one. An IP interface has an IP address and usually a netmask associated with it. Netmasks on point-to-point interfaces like a PPP link are generally not used.

If you set the Framed-IP-Netmask attribute in a radius profile, you are setting the netmask of the interface on the side of the . The Framed-IP-Netmask attribute is NOT something you can set to influence the netmask on the side of the dialin user. And usually, that makes no sense anyway even if you could set it.

The result of this on most NAS is that they start to route a subnet (the subnet that contains the assigned IP address and that is as big as the netmask indicates) to that PPP interface and thus to the user. If that is exactly what you want, then that’s fine, but if you do not intend to route a whole subnet to the user, then by all means do NOT use the Framed-IP-Netmask attribute.

Many interpret a left-out as if it were set to 255.255.255.255, but to be certain you should set the Framed-IP-Netmask to 255.255.255.255.

For example, the following entries do almost the same on most :

The result is that the end user gets IP address 192.168.5.78 and that the whole network with IP addresses 192.168.5.64 - 195.64.5.79 is routed over the PPP link to the user (see the s for the exact syntax of the Framed-Route attribute).

The ldap module can only work with PAP passwords since it needs to send the clear text user password to the LDAP server to authenticate the user. There are however provisions to extract the user password from the LDAP and make it available to the server core and the chap module. See for more details on how to configure the ldap module to do that.

There are a few things that the administrator should watch out for though:

If you have control over NAS, then set it to accept only PAP authentication. If you do that, all clients will "listen" and use only PAP. In that case there is no need to configure anything on the client(s).

Please see: Why do Acct-Input-Octets and Acct-Output-Octets wrap at 4 GB?

FreeRADIUS 1.1.x does not particularly care if the host it runs on is dual-stack. It will work just fine, but only use the IPv4 stack of the machine. It will also transport IPv6 RADIUS attributes just fine but will NOT send packets over IPv6.

FreeRADIUS Server 2.0.0 and greater has full support for both IPv6 attributes and IPv6 network packets.

RADIUS related RFCs and Drafts are archived at: * http://www.freeradius.org/rfc/