FreeRADIUS Frequently Asked Questions & Answers
$Id: FAQ.freeradius,v 1.14 2004/05/31 17:43:32 freerad Exp $
maintained by Antonio Dias accdias at sst dot com dot br
original work by Vladimir Ivaschenko hazard dot bsn at maks dot net
with many questions answered by Alan DeKok aland at ox dot org
This is the FAQ (Frequently Asked Questions) for the FreeRADIUS Server
(freeradius for short) development project. It contains both general and
technical information about FreeRADIUS: project 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 Radiusd to mailing list to
see if your question is already answered here first.
That is, PLEASE read the FAQ. Question 4.11, especially, is VERY important.
This FAQ is posted monthly to the following mailing list:
o FreeRADIUS Users Mailing List
freeradius-users@lists.cistron.nl
o Search the list at
http://www.mail-archive.com/freeradius-users@lists.cistron.nl/
It is available at the following WWW pages:
o FreeRADIUS Project official site
http://www.freeradius.org/faq/
Section 1 - Overview
1.1 What is FreeRADIUS and what is it supposed to do?
1.2 How it differs from other radius servers?
1.3 On what platforms does it run?
1.4 Who uses FreeRADIUS?
Section 2 - Where to get information
2.1 Is there a WWW site set up for FreeRADIUS information?
2.2 Is there a mailing list for FreeRADIUS?
2.2.1 Is there an archive of freeradius-users mailing list?
2.3 Is there a mailing list for FreeRADIUS developers?
2.3.1 Is there an archive of freeradius-devel mailing list?
Section 3 - How to Find, Install, Configure FreeRADIUS
3.1 Where can I get FreeRADIUS?
3.1.1 Are there RPM packages of FreeRADIUS?
3.2 How do I install FreeRADIUS?
3.3 Is there a way to bind FreeRADIUS to a specific IP address?
3.4 Can I run FreeRADIUS under daemontools control?
Section 4 - Common problems and their solutions
4.1 Incoming Authentication-Request passwords are all garbage. Why?
4.2 The NAS seems to ignore the reply of the radius server. Why?
4.3 Where is the program to kick users offline using radius?
4.4 PAP Authentication works, but CHAP fails. Why?
4.4.1 But CHAP is more secure, isn't it?
4.5 What's with the commas in the raddb/users file?
4.6 3Com/USR HiPerArc doesn't work.
4.7 Simultaneous-Use doesn't work.
4.7.1 3Com/USR HiPerArc Simultaneous-Use doesn't work.
4.7.2 Cisco Simultaneous-Use doesn't work.
4.7.3 Ascend MAX 4048 Simultaneous-Use doesn't work.
4.8 The server is complaining about invalid user route-bps-asc1-1,
along with lots of others. Why?
4.9 Why FreeRADIUS is taking so long to start?
4.10 Why radwho is taking so long to show the users list?
4.11 It still doesn't work!
4.12 Debugging it yourself.
4.13 But it worked with another RADIUS server!
4.14 It says "Could not link ... file not found", what do I do?
Section 5 - How do I .... ?
5.1 ... send a message to PPP users?
5.2 ... deny access to a specific user, or group of users?
5.3 ... use Login-Time for groups, not for users?
5.4 ... enable FreeRADIUS to log accounting attribute type X?
5.5 ... permit access to any user regardless of password?
5.6 ... limit access to only POP3 and SMTP?
5.7 ... use PAM with FreeRADIUS?
5.8 ... get radius to pick up changes in the raddb/users file?
5.9 ... check the configuration before sending a HUP to the server?
5.10 ... tell the user what to use for an IP netmask?
5.11 ... make CHAP work with LDAP
Section 6 - References
Section 7 - Acknowledgments
Section 1 - Overview
1.1 What is FreeRADIUS and what is it supposed to do?
FreeRADIUS Server or freeradius is a daemon for un*x operating
systems which allows one to set up (guess what!) a radius protocol server,
which is usually used for authentication and accounting of dial-up users.
To use server, you also need a correctly setup client which will talk to it,
usually a terminal server or a PC with appropriate which emulates it
(PortSlave, radiusclient etc).
It is being developed by several people that 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:
o Access based on huntgroups
o Multiple DEFAULT entries in raddb/users file
o All users file entries can optionally "fall through"
o Caches all config files in-memory
o Keeps a list of logged in users (radutmp file)
o "radwho" program can be installed as "fingerd"
o Logs both UNIX wtmp file format and RADIUS detail logfiles
o Supports Simultaneous-Use = X parameter. Yes, this means that you
can now prevent double logins!
o Supports Vendor-Specific attributes, including USR non-standard
ones.
o Supports proxying
o Supports the "Alive" packet
o 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.
o Supports PAM
More information is available in the documentation.
2.1 Is there a WWW site set up for FreeRADIUS information?
Yes, the FreeRADIUS Server WWW site is at
http://www.freeradius.org/
It contains the new server, documentation, and additional RADIUS programs.
Note that this server is NOT ready for public use.
Yes. It's a mailman list, meaning you can subscribe to it using your web
browser. Simply go to http://lists.cistron.nl, click on "freeradius-users" and
follow the instructions.
You can also use email to subscribe, mail to:
freeradius-users-request@lists.cistron.nl
with the following line in the message body:
subscribe freeradius-users
2.2.1 Is there an archive of freeradius-users mailing list?
2.3 Is there a mailing list for FreeRADIUS development ?
Yes. It's a mailman list, meaning you can subscribe to it using your web
browser. Simply go to http://lists.cistron.nl/, click on "freeradius-devel"
and follow the instructions.
You can also use email to subscribe, mail to:
freeradius-devel-request@lists.cistron.nl
with the following line in the message body:
subscribe freeradius-devel
2.3.1 Is there an archive of freeradius-devel mailing list?
bash$ tar zxvf freeradius-[version].tar.gz
bash$ ./configure
bash$ make
bash$ su - root
bash# make install
Don't forget to read supplied documentation first, including the
configuration files. As with many free software projects, FreeRADIUS
could use more documentation. Until such documentation is available,
the only place that configuration items are documented is in the
configuration files themselves.
If you have problems when trying to run FreeRADIUS, and you see error
messages like:
rlm_sql: Could not link driver rlm_sql_mysql: file not found
Then the shared libraries on your system are misconfigured. See
question and answer 4.14, below.
Also, in the future you might be able to get pre-compiled versions of
FreeRADIUS for different platforms, links are available at the
official WWW site.
3.3 Is there a way to bind FreeRADIUS to a specific IP address?
Yes - see the manual page. You can specify an IP address to bind to with the
-i ipaddr command line option.
3.4 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:
o The log account and group name (I use log.log in this example).
Logging programs run under this account.group. If this
account.group pair do not exist yet, create it now.
o The radiusd local service directory (I use /etc/radiusd in
this example). This is where radiusd will store logs and a
few configuration files.
Here are the steps I did (just once):
bash# groupadd log
bash# useradd -g log log
bash# mkdir /etc/radiusd
bash# mkdir /etc/radiusd/log
bash# mkdir /etc/radiusd/log/main
bash# chmod +t+s /etc/radiusd /etc/radiusd/log
bash# 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:
bash# cd /etc/radiusd
bash# 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
bash# cd /etc/radiusd/log
bash# cat run
#!/bin/sh
exec setuidgid log multilog t ./main
To make service starts do (just once):
bash# ln -sf /etc/radiusd /service
Now you can send signals to radiusd using the svc program. Here are some
interesting ones:
To hang-up it (reload config) do:
bash# svc -h /service/radiusd
To temporarly disable it (down) do:
bash# svc -d /service/radiusd
To reenable it (up) do:
bash# svc -u /service/radius
Section 4 - Common problems and their solutions
4.1 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 -xxyz -l stdout
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 16 characters for the shared
secret.
4.2 The NAS seems to ignore the reply of the radius server. Why?
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 modify the startup script and add the -i address
option to the radiusd command line. This will bind the server to specifically
that IP address. It will only listen to that address and replies will always go
out with that address as the source address.
4.3 Where is the program to kick users offline using radius?
It's impossible to do using radius, as radius doesn't do that.
However, Jason Straight wrote a program called radkill, which does just that:
radkill is a TCL program 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 is available for download at
ftp://ftp.nmo.net/pub/radkill/radkill-latest.tar.gz
If that doesn't work, try using SNMP.
You're not using plaintext passwords in the raddb/users file.
According to Miquel van Smoorenburg in message
7pcrpn$qi$1@defiant.cistron.net on the cistron-radius list:
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.
4.4.1 But CHAP is more secure, isn't it?
Not really.
Q: Does Section 4.4 really mean I must leave a file lying around with
cleartext passwords for the more than 400 people who'll be using this
thing?
A: Yes.
So what do ISP with (tens of?) thousands of customers do?
You have 2 choices:
1. 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.
2. You don't allow CHAP, just PAP. Advantage: you don't store
cleartext passwords on your system. Disadvantage: passwords go
in 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.
4.5 What's with the commas in the raddb/users file?
Harry Hinteman Harry at staffassoc dot com wrote:
> Can anyone give me a quick lesson on what the commas do in the users file,
> and how you know when to use them and when you don't .
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.
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.
Here is a check list:
1) Check that you added your NAS to raddb/naslist and selected correct
NAS type. Also check raddb/naspasswd.
2) Run radiusd -sx and see if it parses the Simultaneous-Use line.
3) Try to run radcheck.pl manually; maybe you may have a wrong version
of perl, don't have cmu-snmp installed etc.
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.
by Robert Dalton 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) = /^.*\"([^"]+)".*$/;
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.
4.7.3 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
4.8 The server is complaining about invalid user route-bps-asc1-1,
along with lots of others. Why?
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
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.
4.10 Why radwho is taking so long to show users connected?
Stop right there. Before going any further, be sure that you have
included the following items in your request for help:
o relevant portion from the raddb/users file
o debugging output (using flags -xxyz -l stdout) from radiusd
o 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:
http://lists.cistron.nl/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:
1. Run the server in debugging mode
radiusd -sfxxyz -l stdout
2. 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. See Q 4.9
3. Ensure that you have localhost in your raddb/clients file. FreeRADIUS
comes configured this way, so it should be there.
4. 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 Password == "bob"
Reply-Message = "Hello, bob"
5. 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
6. 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.
7. 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?
8. If authentication works from a different machine then you have the server
set up correctly.
9. 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:
1. ALWAYS test your configurations running the server in debugging mode
radiusd -xxyz -l stdout
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.
2. Read RFC 2138 to see what the RADIUS attributes are and how they work.
3. 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.
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.
4.14 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) 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.
2) 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.
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 http://www.rockstar.com.
5.2 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 any
thing, 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"
5.3 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"
5.4 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.
5.5 How do I permit access to any user regardless of password?
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.
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 bruno at openline dot com dot br 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 ;>
5.8 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
Note that you need at least 1.6.4 for the radiusd -C invocation to work.
Of course a Makefile is suited perfectly for this kind of stuff.
5.9 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 the configuration files.
The problem with this approach is that any syntax errors in the configuration
file may cause your main radius server to die! No one wants this to happen so
there should be some process of checking the configuration files prior to
re-starting the server.
For versions prior to 1.6.4, you can use the following script:
ftp://ftp.freeradius.org/pub/radius/contrib/check-radiusd-config.sh
With 1.6.4 and later, you can simply use
radiusd -C
to check the configuration. It will print the status and exit with a zero exit
status if everything is fine or with a non-zero exit status if errors were found
in the configuration.
In the example script in the paragraph above this has already been used.
5.10 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 NASes 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.
Almost (all?) NASes interpret a left-out Framed-IP-Netmask as if
it was set to 255.255.255.255. So if you somehow feel a certain
need to set the Framed-IP-Netmask to anything, set it to
255.255.255.255.
For example, the following entries do almost the same on most NASes:
user Auth-Type = Local, Password = "blegh"
Service-Type = Framed-User,
Framed-Protocol = PPP,
Framed-IP-Address = 192.168.5.78,
Framed-IP-Netmask = 255.255.255.240
user Auth-Type = Local, 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).
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 doc/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:
o 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.
o 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.
o An 'authtype CHAP' subcomponent should be added in the authenticate section of
radiusd.conf which will contain the chap module.
