Quick Links

• Wiki Home
• Concepts for beginners
• Basic Configuration
• Pre-built packages
• Installing from source code
• Troubleshooting
• Contributing with GitHub
• Browse the Source
• Main web site

Always use radiusd -X when debugging!

FreeRADIUS Frequently Asked Questions

This is the FAQ (Frequently Asked Questions) for the FreeRADIUS Server (freeradius for short) development project. It contains both general and technical information about the FreeRADIUS projects' status, what it is and what it does, how to obtain and configure and run it, and more. Please read this FAQ carefully before you post questions about FreeRADIUS to the mailing lists to see if your question is already answered here first.

FreeRADIUS Overview

What is FreeRADIUS and what is it supposed to do

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

How does it differ from other radius servers?

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:

• Access based on huntgroups
• Multiple DEFAULT entries in raddb/users file
• All users file entries can optionally "fall through"
• Caches all config files in-memory
• Keeps a list of logged in users (radutmp file)
• "radwho" program can be installed as "fingerd"
• Logs both UNIX wtmp file format and RADIUS detail logfiles
• Supports Simultaneous-Use = X parameter. Yes, this means that you can now prevent double logins!
• Supports Vendor-Specific attributes, including USR non-standard ones.
• Supports proxying
• Supports the "Alive" packet
• Exec-Program-Wait, allows you to set up an external program which is executed after authentication and outputs a list of A/V pairs which is then added to the reply.
• Supports PAM

What platforms does it run on?

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

Where to get information

Is there a FreeRADIUS Web site?

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

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

Is there any mailing list for FreeRADIUS?

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.

How to Find and Install FreeRADIUS?

Where can I get FreeRADIUS?

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

• http://www.freeradius.org/

Sources are available at:

• ftp://ftp.freeradius.org/pub/radius/

Where can I get binary packages of FreeRADIUS

Please see the list of available packages.

You may also easily build a package from source.

How do I build and install FreeRADIUS from source?

See the instructions on how to build FreeRADIUS.

Common system setup issues

Is there a way to bind FreeRADIUS to a specific IP address?

Yes - there are several ways to accomplish this.

• The deprecated old way is to specify an IP address with the _-i {IP} command-line option.
• The better way is to use the listen directive in radiusd.conf. listen { ipaddr = 192.168.1.250 port = 1817 type = auth }

You may specify multiple listen directives.

• The third way bind_address = 192.168.1.250 port = 1817

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.

Can I run FreeRADIUS under daemontools control?

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 thisaccount.group pair does not exist yet, create it now.

1. The radiusd local service directory (_/etc/radiusd_ is used in this example). This is where radiusd will store logs and a few configuration files.

Then perform these steps:

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 running a shell script called "run" from /etc/radiusd. Here are the contents of /etc/radiusd/run:

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

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

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

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

ln -sf /etc/radiusd /service

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:

svc -h /service/radiusd

To temporarly disable it (down) do:

svc -d /service/radiusd

To reenable it (up) do:

svc -u /service/radius

Common problems and their solutions

Incoming Authentication-Request passwords are all garbage. Why?

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

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

There are two possible causes of this problem.

Gigawords not enabled on NAS

Some NAS do not send "Gigawords" attributes by default. Read your NAS documentation and configure it to send the attributes Acct-Input-Gigawords and Acct-Output-Gigawords.

For Cisco IOS, this usually achieved by entering

aaa accounting gigawords

(which, by "ingenious" design, requires a reload of the device on certain IOS versions).

Old FreeRADIUS SQL Queries and Table Structure

Older versions of FreeRADIUS (prior to 1.1.7) include support for logging 64-Bit counters to both the detail file and SQL modules but only the PostgreSQL module had this support configured by default.

The detail files will simply log two distinct Attributes (Acct-Input-Octets + Acct-Input-Gigawords and Acct-Output-Octets + Acct-Output-Gigawords).

The PostgreSQL module stores the data as a 64-bit integer (BIGINT) in one column each: AcctInputOctets and AcctOutputOctets.

FreeRADIUS 1.1.7 and greater supports 64-bit counters in other SQL modules, with the same semantics as PostgreSQL.

The following procedure is recommended to enable proper support for 64-bit counters in FreeRADIUS 1.1.6 and earlier:

Modify Database Schema

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 theALTER TABLE command:

MySQL

ALTER TABLE radacct CHANGE AcctInputOctets AcctInputOctets BIGINT(20);
ALTER TABLE radacct CHANGE AcctOutputOctets AcctOutputOctets BIGINT(20);

Oracle

ALTER TABLE radacct MODIFY (AcctInputOctets NUMERIC(19));
ALTER TABLE radacct MODIFY (AcctOutputOctets NUMERIC(19));

Modify FreeRADIUS Queries

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 NAS into one single 64-bit integer stored in the database.

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

'%{Acct-Input-Gigawords:-0}' << 32 | '%{Acct-Input-Octets:-0}'

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

'%{Acct-Output-Gigawords:-0}' << 32 | '%{Acct-Output-Octets:-0}'

Why does the NAS ignore the RADIUS server's reply?

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?

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 (#Is 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.

VSA in Access-Reject

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

How can I disconnect user with 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.

Packet of Disconnect

Packet of Disconnect is the standard and recommended method to disconnect users. It is supported by many newer NAS and uses a RADIUS packet (usually sent to port 3799 although some NAS use 1700 (Mikrotik for example)) to signal that a NAS should terminate an active session.

SNMP

Many NAS support SNMP which can usually (among other things) be used to disconnect users, however implimentation details vary. Read your NAS documentation to find out whether it supports this, and whichMIB to use.

radkill

radkill is a TCL program written by Jason Straight for FreeRADIUS users that monitors ISP users' online times and disconnects them if they are over their call limit. It also monitors the number of users online and will disconnect the users with the least time left to always keep lines open. It's very configurable for multiple NAS setups.

The source archive should be available for download at: ftp://ftp.nmo.net/pub/radkill/radkill-latest.tar.gz

PAP authentication works 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.

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

Auth-Type = Local, Password = "stealme"

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

Auth-Type = System

or anything else that tickles your fancy.

But CHAP is more secure, isn't it?

Not really.

Q: So doesn't using CHAP really mean I must leave a file lying around with cleartext passwords for the hundreds/thousands of people who'll be using this thing?

A: Yes.

So what do ISP with (tens of?) thousands of customers do?

You have 2 choices:

• You allow CHAP and store all the passwords plaintext

  • Advantage: passwords don't go cleartext over the phone line between the user and the terminal server
  • Disadvantage: You have to store the passwords in cleartext on the server

• You don't allow CHAP, just PAP

  • Advantage: you don't store cleartext passwords on your system
  • Disadvantage: passwords going cleartext over the phone line between the user and the terminal server

Now, people say CHAP is more secure. Now you decide which is more likely:

• The phone line between the user and the terminal server gets sniffed and a cracker (a GOOD one) intercepts just one password
• Your radius server is hacked into and a cracker gets ALL passwords of ALL users.

Right. Still think CHAP is more secure? I thought so.

This is a limitation of the CHAP protocol itself, not the RADIUS protocol. The CHAP protocol requires that you store the passwords in plain-text format.

What's with the commas in the raddb/users file?

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

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

Where the dots means 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.

How do the Attribute Operators work?

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

3Com/USR HiPerArc doesn't work

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

Mon Jul 26 15:18:54 1999: Error: Accounting: logout: entry for NAS tc-if5 port 1 has wrong ID

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.

Simultaneous-Use doesn't work

Here is a check list:

1. Check that you added your NAS to raddb/clients.conf and selected correct NAS type, also check the password
2. Run radiusd -X and see if it parses the Simultaneous-Use line.
3. Try to run checkrad manually; maybe you may have a wrong version of perl, don't have cmu-snmp installed etc.
4. run radwho. If it says no one is logged in, Simultaneous-Use won't work.
5. Verify that the NAS is sending accounting packets. Without accounting packets, Simultaneous-Use will NOT work.
6. Verify that the accounting packets are accepted by the radutmp module. If the module returns "noop", it means that the accounting packets do not have enough information for the server to perform Simultaneous-Use enforcement.
7. In case you have SQL as a database, and you have accounting records in radacct table, you'll need to uncomment sql in session section of radiusd.conf file. Also, you'll need to uncomment Simutaneus check query in sql.conf file.

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.

3Com/USR HiPerArc Simultaneous-Use doesn't work

by Robert Dalton [mailto:support-at-accesswest-dot-com support at accesswest dot com]

Verify if you are using HiPerArc software version V4.2.32 release date 09/09/99

In order for simultaneous logins to be prevented reported port density must be set to 256 using the command :

set pbus reported_port_density 256

Otherwise it changes the calculations of the SNMP object ID's.

There is a bug in effected versions of checkrad namely the line under the subroutine "sub_usrhiper". The line that should be commented out is:

($login) = /^.*\"([^"]+)".*$/;

Cisco Simultaneous-Use doesn't work

Q: I am getting the following in radius.log file:

Thu Oct 21 10:59:01 1999: Error: Check-TS: timeout waiting for checkrad

What's wrong?

A: Verify if you have SNMP enabled on your CISCO router, check the existence of the following line:

snmp-server community public RO 97

where 97 is the access-list that specifies who gets access to the SNMP info. You should also have a line like this:

access-list 97 permit A.B.C.D

where A.B.C.D is the ip address of the host running the radius server.

Ascend MAX 4048 Simultaneous-Use doesn't work

Q: I am getting the following in radius.log file:

Thu Oct 21 10:59:01 1999: Error: Check-TS: timeout waiting for checkrad

What's wrong?

A: Verify that you have the MAX 4048 setup in your naslist as max40xx and that you have Finger turned on.

Ethernet->Mod Config->Finger=Yes

The server is complaining about invalid user route-bps-asc1-1, along with lots of others

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

Ethernet->Mod Config->Auth->Allow Auth Config Rqsts = No

Why FreeRADIUS is taking so long to start?

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.

Why radwho is taking so long to show users connected?

See question 4.9

PEAP or EAP-TLS Doesn't Work with a Windows machine

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

It still doesn't work!

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

• relevant portion from the raddb/users file
• debugging output (using flag -X) from radiusd
• output from radtest, when run on the same machine as radiusd

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

Debugging it yourself

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

1. Install "screen" (if not already installed).
2. Run a new screen and name it something convenient (eg. screen -S radiusd)
3. Hit "Ctrl+A-H" to log all console output to a file.
4. Start "radiusd -X" (FreeRADIUS is now running in this screen, and everything is being stored to log file. At any time, you can detach from the screen with Ctrl+A-d and reattach to the screen (both from local and over SSH) with screen -r to see what is going on in real time.)
5. The server SHOULD print out: Ready to process requests.
   • If it doesn't, then it should print out an error message. Read it.
   • If it takes a long time to start up, and THEN prints out the message, then your DNS is broken.
6. Ensure that you have localhost in your raddb/clients file. FreeRADIUS comes configured this way, so it should be there.
7. Ensure you have a valid user in your raddb/users file. If everything else fails, go to the top of the file and add the following entry: bob Cleartext-Password := "bob" Reply-Message = "Hello, bob"
8. Run the radtest program from the LOCAL machine, in another window. This will tell you if the server is alive and is answering requests. radtest bob bob localhost 0 testing123
9. Ensure that you see the Reply-Message above and that you do NOT see an "Access denied" message. If you get an Access-Accept message, this means that the server is running properly.
10. Configure another machine as a RADIUS client and run radtest from that machine too. You SHOULD see the server receive the request and send a reply.
    • If the server does NOT receive the request then the ports are confused. RADIUS historically uses 1645/UDP, where RFC 2138 and many new systems use the proper value of 1812/UDP. See/etc/services or use the -p option to specify a different port.
    • Run tcpdump in another window on the RADIUS client machine. Use the command:
    • tcpdump udp
    • Look CAREFULLY at the packets coming from the RADIUS server. Which address are they coming from? Which port?
11. If authentication works from a different machine then you have the server set up correctly.
12. Now you should use a more complicated configuration to see if the server receives and replies with the attributes you want. There is little information that can be offered here in the FAQ as your individual systems configuration can not be predicted. However, a few hints can help:
    • ALWAYS test your configurations running the server in debugging mode if you want to debug a problem. If you do not do so then DO NOT expect anyone else to be able to help you.
    • radiusd -X
    • Read RFC 2138 to see what the RADIUS attributes are and how they work
    • ALWAYS starts with a simple configuration in place of a more complicated one. You should not expect to be able to debug a complicated configuration entry by sending one packet, and looking at the trace.
    • Make the configuration as simple as possible, EVEN IF it doesn't do exactly what you want. Then, repeatedly, try to authenticate and see if it works. If authentication succeeds, then you can gradually add more attributes to the configuration to get the entry you desire.

But it worked with another RADIUS server!

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.

It says "Could not link ... file not found", what do I do?

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:

1) 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

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:

./configure --disable-shared
make
make install

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.

I see only one radiusd in the process list. What is wrong?

If you have configured FreeRADIUS 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:

• ps -efm
• ps auxm

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

• ps -efL
• ps auxH

How do I ... ?

How do I send a message to PPP users?

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 athttp://www.rockstar.com.

How do I deny access to a specific user, or group of users?

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.

foo Auth-Type := Reject
    Reply-Msg = "foo is not allowed to dial-in"

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

DEFAULT Group == "disabled", Auth-Type := Reject
    Reply-Message = "Your account has been disabled"

How do I log failed login attempts in a SQL database?

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:

postauth_query = "INSERT into radpostauth (user, pass, date) values ('%{User-Name}', '%{User-Password:-Chap-Password}', '%S')"

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 [http://freeradius.org/radiusd/doc/Post-Auth-Type Post-Auth-Type REJECT]. For example:

post-auth {
    # Login successful: get an address from the IP pool.
    ippool

    Post-Auth-Type REJECT {
    # Login failed: log to SQL database.
        sql
    }
}

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

How do I use Login-Time for groups, not for users?

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

DEFAULT Group == "daysonly", Login-Time := "0800-2000"

or

DEFAULT Group == "daysonly", Login-Time := "Any0800-2000"

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

DEFAULT Group == "weekdays", Login-Time := "Wk0800-2000"

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

DEFAULT Group == "weekends", Login-Time := "Sa-Su0800-2000"

How do I enable FreeRADIUS to log accounting attribute type X?

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.

How do I permit access to any user regardless of password?

Edit raddb/users, on top of it put

DEFAULT Auth-Type := Accept

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.

How do I limit access to only POP3 and SMTP?

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:

foo Auth-Type := System
    Framed-Filter-Id += "160.in"
    Framed-Filter-Id += "161.out"
    Fall-Through = Yes

CISCO's config must have:

aaa authorization network default radius
ip access-list extended 160
permit ip ...
ip access-list extended 161
permit ip ...

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

How do I use PAM with FreeRADIUS?

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 also says:

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

auth required /lib/security/pam_userdb.so crypt db=/etc/raddb/data/users
auth required /lib/security/pam_listfile.so item=user sense=allow file=/etc/raddb/data/somehunt.allow onerr=fail
auth required /lib/security/pam_nologin.so
account required /lib/security/pam_userdb.so

and

DEFAULT Huntgroup-Name ="somehunt", Auth-Type=PAM, Pam-Auth="radhunt", Simultaneous-Use=1
    Fall-Through = Yes

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

How do I get radius to pick up changes in the raddb/users file?

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:

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

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:

#! /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

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

How do I check the configuration before sending a HUP to the server?

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 067279

Example for broken configuration (users) file:

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

Example for 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

Note however, that this option is not available in freeradius 1.x. The freeradius distribution contains a check-radiusd-config script which checks the configuration by starting a second server on a different port and waiting for it to crash or not to crash...

How do I send multiple values for an attribute ?

Use the following configuration :

Framed-Route := "10.130.1.252/32 0.0.0.0  5",
Framed-Route += "10.130.0.252/32 0.0.0.0 10",</pre>

Which gives : (tcpdump output)

Framed Route Attribute (22), length: 28, Value: 10.130.1.252/32 0.0.0.0  5
  0x0000:  3130 2e31 3330 2e31 2e32 3532 2f33 3220
  0x0010:  302e 302e 302e 3020 2035
Framed Route Attribute (22), length: 28, Value: 10.130.0.252/32 0.0.0.0 10
  0x0000:  3130 2e31 3330 2e30 2e32 3532 2f33 3220
  0x0010:  302e 302e 302e 3020 3130

How do I tell the user what to use for an IP netmask?

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 NAS. 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 NAS interpret a left-out Framed-IP-Netmask 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 NAS:

user Cleartext-Password := "blegh"
    Service-Type = Framed-User,
    Framed-Protocol = PPP,
    Framed-IP-Address = 192.168.5.78,
    Framed-IP-Netmask = 255.255.255.240

user Cleartext-Password := "blegh"
    Service-Type = Framed-User,
    Framed-Protocol = PPP,
    Framed-IP-Address = 192.168.5.78,
    Framed-Route = "192.168.5.64/28 0.0.0.0 1"

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 RADIUS RFCs for the exact syntax of the Framed-Route attribute).

How do I make CHAP work with LDAP?

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 rlm_ldap 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:

• Add the chap module in the authorize section of radiusd.conf before any other modules which set the Auth-Type attribute. That way the chap module can check if the current request contains a PAP or CHAP password and if it contains the former then it will set the Auth-Type to CHAP.
• The := operator should not be used in the users file to set the Auth-Type since it will set the Auth-Type regardless of wether it has already being set to some other value.
• An 'authtype CHAP' subcomponent should be added in the authenticate section of radiusd.conf which will contain the chap module.

How do I make Windows XP clients use only PAP (Not CHAP)

• Go to Network Connections an open Properties for this connection.
• Select Security tab
• Click on Advanced radio button, and then on Settings button
• Leave only PAP ticked
• Click OK, OK to set it

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

How do I enable logging of 64 bit counters, a.k.a.Acct-{Input|Output}-Gigawords?

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

Does FreeRADIUS Support IPv6?

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.

References

FreeRADIUS Related Web Pages

• FreeRADIUS Web Page
• FreeRADIUS Wiki
• Cistron RADIUS Web Page
• FreeRADIUS on Red Hat systems

Mailing Lists

• FreeRADIUS Users Mailing List Subscription
• FreeRADIUS Users Mailing List Archive
• FreeRADIUS Developers Mailing List Subscription
• FreeRADIUS Developers Mailing List Archive

RADIUS RFC and Drafts

RADIUS related RFCs and Drafts are archived at:

• http://www.freeradius.org/rfc/

Acknowledgments

FreeRADIUS is the result of the work done by a large number of people.

The major contributors are listed on the Acknowledgments page.