5.2 Installing FreeRADIUS

At present, the FreeRADIUS team doesn't offer precompiled binaries. The best way to start off is to grab the latest source code, compressed using tar and gzip , from the FreeRADIUS web site at http://www.freeradius.org. Once the file is on your computer, execute the following command to uncompress the file:

 tar -zxvf freeradius.tar.gz 

Next, you'll need to compile FreeRADIUS. Make sure your system at least has gcc , glibc , binutils , and gmake installed before trying to compile. To begin compiling, change to the directory where your uncompressed source code lies and execute ./configure from the command line. You can also run ./configure -flags and customize the settings for the flags in Table 5-1.

Table 5-1. Optional configuration flags for FreeRADIUS

Flag

Purpose

Default

 --enable-shared[=PKGS] 

Builds shared libraries.

Yes

 --enable-static[=PKGS] 

Builds static libraries.

Yes

 --enable-fast-install[=PKGS] 

Optimizes the resulting files for fastest installation.

Yes

 --with-gnu-ld 

Makes the procedure assume the C compiler uses GNU lD .

No

 --disable-libtool-lock 

Avoids locking problems. This may break parallel builds.

Not applicable

 --with-logdir=DIR 

Specifies the directory for log files.

 LOCALSTATEDIR/log 
 --with-radacctdir=DIR 

Specifies the directory for detail files.

 LOGDIR/radacct 
 --with-raddbdir=DIR 

Specifies the directory for configuration files.

 SYSCONFDIR/raddb 
 --with-dict-nocase 

Makes the dictionary case insensitive.

Yes

 --with-ascend-binary 

Includes support for attributes provided with the Ascend binary filter.

Yes

 --with-threads 

Uses threads if they're supported and available.

Yes

 --with-snmp 

Compiles SNMP support into the binaries.

Yes

 --with-mysql-include-dir=DIR 

Specifies where the include files for MySQL can be found.

Not applicable

 --with-mysql-lib-dur=DIR 

Specifies where the dictionary files for MySQL can be found.

Not applicable

 --with-mysql-dir-DIR 

Specifies where MySQL is installed on the local system.

Not applicable

 --disable-ltdl-install 

Does not install libltdl .

Not applicable

 --with-static-modules=QUOTED-MODULE-LIST 

Compiles the list of modules statically.

Not applicable

 --enable-developer 

Turns on extra developer warnings in the compiler.

Not applicable

Commonly, the following locations are used when installing a RADIUS product (these practices go back to the Cistron RADIUS server):

Binaries

/usr/local/bin and /usr/local/sbin

Manual (man) pages

/usr/local/man

Configuration files

/etc/raddb

Log files

/var/log and /var/log/radacct

To make the compiler use these locations automatically, execute:

 ./configure --localstatedir=/var --sysconfdir=/etc 

The programs will then be configured to compile. The rest of this chapter will assume that you installed FreeRADIUS in these locations.

Next, type make . This will compile the binaries. Finally, type make install . This will place all of the files in the appropriate locations. It will also install configuration files if this server has not had a RADIUS server installed before. Otherwise, the procedure will not overwrite your existing configuration and will report to you on what files it did not install.

At this point, your base FreeRADIUS software is installed. Before you begin, though, you'll need to customize some of the configuration files so that they point to machines and networks specific to your configuration. Most of these files are located in /etc/raddb . The following files are contained by default:

 radius:/etc/raddb # ls -al total 396 drwxr-xr-x    2 root     root         4096 Apr 10 10:39 . drwxr-xr-x    3 root     root         4096 Apr 10 10:18 .. -rw-r--r--    1 root     root          635 Apr 10 10:18 acct_users -rw-r--r--    1 root     root         3431 Apr 10 10:18 attrs -rw-r--r--    1 root     root          595 Apr 10 11:02 clients -rw-r--r--    1 root     root         2235 Apr 10 10:39 clients.conf -rw-r--r--    1 root     root        12041 Apr 10 10:18 dictionary -rw-r--r--    1 root     root        10046 Apr 10 10:39 dictionary.acc -rw-r--r--    1 root     root         1320 Apr 10 10:39 dictionary.aptis -rw-r--r--    1 root     root        54018 Apr 10 10:39 dictionary.ascend -rw-r--r--    1 root     root        11051 Apr 10 10:39 dictionary.bay -rw-r--r--    1 root     root         4763 Apr 10 10:39 dictionary.cisco -rw-r--r--    1 root     root         1575 Apr 10 10:39 dictionary.compat -rw-r--r--    1 root     root         1576 Apr 10 10:39 dictionary.erx -rw-r--r--    1 root     root          375 Apr 10 10:39 dictionary.foundry -rw-r--r--    1 root     root          279 Apr 10 10:39 dictionary.freeradius -rw-r--r--    1 root     root         2326 Apr 10 10:39 dictionary.livingston -rw-r--r--    1 root     root         2396 Apr 10 10:39 dictionary.microsoft -rw-r--r--    1 root     root          190 Apr 10 10:39 dictionary.nomadix -rw-r--r--    1 root     root         1537 Apr 10 10:39 dictionary.quintum -rw-r--r--    1 root     root         8563 Apr 10 10:39 dictionary.redback -rw-r--r--    1 root     root          457 Apr 10 10:39 dictionary.shasta -rw-r--r--    1 root     root         2958 Apr 10 10:39 dictionary.shiva -rw-r--r--    1 root     root         1274 Apr 10 10:39 dictionary.tunnel -rw-r--r--    1 root     root        63265 Apr 10 10:39 dictionary.usr -rw-r--r--    1 root     root         2199 Apr 10 10:39 dictionary.versanet -rw-r--r--    1 root     root         1767 Apr 10 10:18 hints -rw-r--r--    1 root     root         1603 Apr 10 10:18 huntgroups -rw-r--r--    1 root     root         2289 Apr 10 10:39 ldap.attrmap -rw-r--r--    1 root     root          830 Apr 10 10:18 naslist -rw-r--r--    1 root     root          856 Apr 10 10:18 naspasswd -rw-r--r--    1 root     root         9533 Apr 10 10:39 postgresql.conf -rw-r--r--    1 root     root         4607 Apr 10 10:39 proxy.conf -rw-r--r--    1 root     root        27266 Apr 10 10:57 radiusd.conf -rw-r--r--    1 root     root        27232 Apr 10 10:39 radiusd.conf.in -rw-r--r--    1 root     root         1175 Apr 10 10:18 realms -rw-r--r--    1 root     root         1405 Apr 10 10:39 snmp.conf -rw-r--r--    1 root     root         9089 Apr 10 10:39 sql.conf -rw-r--r--    1 root     root         6941 Apr 10 10:18 users -rw-r--r--    1 root     root         6702 Apr 10 10:39 x99.conf -rw-r--r--    1 root     root         3918 Apr 10 10:39 x99passwd.sample 

5.2.1 The clients File

First, take a look at the /etc/raddb/clients file. This file lists the hosts authorized to hit the FreeRADIUS server with requests and the secret key those hosts will use in their requests. Some common entries are already included in the /etc/raddb/clients file, so you may wish to simply uncomment the appropriate lines. Make sure the secret key that is listed in the clients file is the same as that programmed into your RADIUS client equipment. Also, add the IP address of a desktop console machine with which you can test your setup using a RADIUS ping utility. A sample clients file looks like this:

 # Client Name           Key #----------------       ---------- #portmaster1.isp.com    testing123 #portmaster2.isp.com    testing123 #proxyradius.isp2.com   TheirKey  localhost               testing123 192.168.1.100           testing123 tc-clt.hasselltech.net  oreilly 

It's recommended by the FreeRADIUS developers that users move from the clients file to the clients.conf file. The clients.conf file will be addressed later in Chapter 6, but for the sake of simplicity and startup testing, I will continue using the plain clients file in this introduction.

While it may seem obvious, change the shared secrets from the defaults in the file or the samples listed previously. Failing to do so presents a significant security risk to your implementation and network.

5.2.2 The naslist File

Next, open the /etc/raddb/naslist file. Inside this file, you should list the full canonical name of every NAS that will hit this server, its nickname, and the type of NAS. For your test console, you can simply use the "portslave" type. Table 5-2 lists the FreeRADIUS-supported NAS equipment and the type identifier needed for the naslist file.

Table 5-2. Supported NAS equipment and its type identifier

NAS equipment

Type identifier

3Com/USR Hiper Arc Total Control

 usrhiper 

3Com/USR NetServer

 netserver 

3Com/USR TotalControl

 tc 

Ascend Max 4000 family

 max40xx 

Cisco Access Server family

 cisco 

Cistron PortSlave

 portslave 

Computone PowerRack

 computone 

Cyclades PathRAS

 pathras 

Livingston PortMaster

 livingston 

Multitech CommPlete Server

 multitech 

Patton 2800 family

 patton 

A sample /etc/raddb/naslist file looks like this:

 # NAS Name              Short Name      Type #----------------       ----------      ---- #portmaster1.isp.com    pm1.NY          livingston localhost               local           portslave 192.168.1.100           local           portslave tc-clt.hasselltech.net  tc.char         tc 

5.2.3 The naspasswd File

If you have 3Com/USR Total Control, NetServer, or Cyclades PathRAS equipment, you may need to edit the /etc/raddb/naspasswd file. This lets the checkrad utility log onto your NAS machine and check to see who is logged on at what portwhich is commonly used to detect multiple logins. Normally, the SNMP protocol can do this, but the equipment listed previously needs a helping hand from the checkrad utility. A sample /etc/raddb/naspasswd file looks like this:

 206.229.254.15 !root JoNAThaNHasSELl 206.229.254.5  !root FoOBaR 

5.2.4 The hints File

Progressing along with the FreeRADIUS setup you will come to the /etc/raddb/hints file. This file can be used to provide "hints" to the RADIUS server about how to provision services for a specific user based on how his login name is constructed . For example, when you've configured your default service to be a SLIP connection, then a SLIP connection will be set up if a user logs in with her standard username (e.g., meis ). However, if that same user wanted a PPP connection, she could alter her username to be Prneis , and the RADIUS server (knowing about that convention from the /etc/raddb/hints file) would set up a PPP connection for her. Suffixes on the end of the username work in the same way. More on the hints file will be provided later in the chapter. You shouldn't need to edit this file initially since we're just testing, but if you'd like to check it out, a sample /etc/raddb/hints file looks like this:

 DEFAULT Prefix = "P", Strip-User-Name = Yes         Hint = "PPP",         Service-Type = Framed-User,         Framed-Protocol = PPP                  DEFAULT Prefix = "S", Strip-User-Name = Yes         Hint = "SLIP",         Service-Type = Framed-User,         Framed-Protocol = SLIP DEFAULT Suffix = "P", Strip-User-Name = Yes         Hint = "PPP",         Service-Type = Framed-User,         Framed-Protocol = PPP                  DEFAULT Suffix = "S", Strip-User-Name = Yes         Hint = "SLIP",         Service-Type = Framed-User,         Framed-Protocol = SLIP 

5.2.5 The huntgroups File

Let's move on to the /etc/raddb/huntgroups file, where you define certain huntgroups. Huntgroups are sets of ports or other communication outlets on RADIUS client equipment. In the case of FreeRADIUS, a huntgroup can be a set of ports, a specific piece of RADIUS client equipment, or a set of calling station IDs that you want to separate from other ports.

You can filter these defined huntgroups to restrict their access to certain users and groups and match a username/password to a specific huntgroup, possibly to assign a static IP address. You define huntgroups based on the IP address of the NAS and a port range. (Keep in mind that a range can be anywhere from 1 to the maximum number of ports you have.) To configure this file, you first specify the terminal servers in each POP. Then, you configure a stanza that defines the restriction and the criteria that a potential user must satisfy to pass the restriction. That criteria is most likely a Unix username or groupname.

Again, you shouldn't have to configure this file to get basic functionality enabled for testing; if you would like to peruse the file and its features, however, I've provided a sample /etc/raddb/huntgroups file. It's for an ISP with a POP in Raleigh, North Carolina that wants to restrict the first five ports on its second of three terminal servers in that POP to only premium customers:

 raleigh        NAS-IP-Address == 192.168.1.101 raleigh        NAS-IP-Address == 192.168.1.102 raleigh        NAS-IP-Address == 192.168.1.103 premium        NAS-IP-Address == 192.168.1.101, NAS-Port-Id == 0-4                Group = premium,                Group = staff 

5.2.6 The users File

FreeRADIUS allows several modifications to the original RADIUS server's style of treating users unknown to the users file. In the past, if a user wasn't configured in the users file, the server would look in the Unix password file, and then deny him access if he didn't have an account on the machine. There was only one default entry permitted. In contrast, FreeRADIUS allows multiple default entries and can "fall through" each of them to find an optimal match. The entries are processed in the order they appear in the users file, and once a match is found, RADIUS stops processing it. The Fall-Through = Yes attribute can be set to instruct the server to keep processing, even upon a match. The new FreeRADIUS users file can also accept spaces in the username attributes, either by escaping the space with a backslash (\) or putting the entire username inside quotation marks. Additionally, FreeRADIUS will not strip out spaces in usernames received from PortMaster equipment.

Since we won't add any users to the users file for our testing purposes, FreeRADIUS will fall back to accounts configured locally on the Unix machine. However, if you want to add a user to the users file to test that functionality, a sample /etc/raddb/users file looks like this:

 steve  Auth-Type := Local, User-Password == "testing"        Service-Type = Framed-User,        Framed-Protocol = PPP,        Framed-IP-Address = 172.16.3.33,        Framed-IP-Netmask = 255.255.255.0,        Framed-Routing = Broadcast-Listen,         Framed-Filter-Id = "std.ppp",        Framed-MTU = 1500,        Framed-Compression = Van-Jacobsen-TCP-IP DEFAULT Service-Type == Framed-User        Framed-IP-Address = 255.255.255.254,        Framed-MTU = 576,        Service-Type = Framed-User,        Fall-Through = Yes DEFAULT Framed-Protocol == PPP        Framed-Protocol = PPP,        Framed-Compression = Van-Jacobson-TCP-IP 

There will be much more about the users file later in this chapter.

5.2.7 The radiusd.conf File

This file is much like Apache's httpd.conf file in that it lists nearly every directive and option for the basic functionality of the FreeRADIUS product. You will need to edit the Unix section of this file to make sure that the locations of the passwd , shadow , and group files are not commented out and are correct. FreeRADIUS needs these locations to start up. The appropriate section looks like this:

 unix {      (some content removed)  #  Define the locations of the normal passwd, shadow, and                 #  group files.                 #                 #  'shadow' is commented out by default, because not all                 #  systems have shadow passwords.                 #                 #  To force the module to use the system passwd fnctns,                 #  instead of reading the files, comment out the 'passwd'                 #  and 'shadow' configuration entries.  This is required                 #  for some systems, like FreeBSD.                 #                 passwd = /etc/passwd                 shadow = /etc/shadow                 group = /etc/group      (some content removed)  } 

I will cover the radiusd.conf file in more detail later in this chapter.

With that done, it's now time to launch the radiusd daemon and test your setup. Execute radiusd from the command line; it should look similar to this:

 radius:/etc/raddb # radiusd radiusd: Starting - reading configuration files ... radius:/etc/raddb # 

If you receive no error messages, you now have a functional FreeRADIUS server. Congratulations!

5.2.8 Testing the Initial Setup

Once you have FreeRADIUS running, you need to test the configuration to make sure it is responding to requests. FreeRADIUS starts up listening, by default, on the port specified either in the local /etc/services file or in the port directive in radiusd.conf . While RFC 2138 defines the standard RADIUS port to be 1812, historically RADIUS client equipment has used port 1645. Communicating via two different ports is obviously troublesome , so many users start the FreeRADIUS daemon with the -p flag, which overrides the setting in both the /etc/services file and anything set in radiusd.conf . To do this, run the following from the command line:

 radius:/etc/raddb # radiusd -p 1645 radiusd: Starting - reading configuration files ... radius:/etc/raddb # 

The server is now running; it is listening for and accepting requests on port 1645.

So, what is an easy way to test your configuration to see if it functions properly? It's easier than you might think, in fact. MasterSoft, Inc. has released a Windows desktop RADIUS server testing tool called NTRadPing, available at http://www.dialways.com. The latest version as of this writing is 1.2, and it's a freeware tool. Download and install this utility on a Windows machine, and then run it. The initial application window should look much like Figure 5-1.

Figure 5-1. The NTRadPing 1.2 application window
figs/rad_0501.gif

To do a quick test, follow these steps:

  1. Enter the IP address of your FreeRADIUS machine in the RADIUS Server/port box, and then the port number in the adjacent box. For this example, I've used IP address 192.168.1.103 and port 1645.

  2. Type in the secret key you added in /etc/raddb/clients for this Windows console machine. For this example, I used the key "testing123."

  3. In the User-Name field, enter root, and in the Password field, enter the root password for your FreeRADIUS machine.

  4. Select Authentication Request from the Request Type drop-down list box.

  5. Click Send.

If your server is working properly, and you entered a valid root password, you should see the reply in the RADIUS Server reply box to the right of the NTRadPing window. You should see something like:

 Sending authentication request to server 192.168.1.103:1645 Transmitting packet, code=1 id=1 length=47 Received response from the server in 15 milliseconds Reply packet code=2 id=1 length=20 Response: Access-Accept ------------------attribute dump---------------------- 

Now, change the password for root inside NTRadPing to something incorrect, and resend the request. You should get an Access-Reject message much like the one shown here:

 Sending authentication request to server 192.168.1.103:1645 Transmitting packet, code=1 id=3 length=47 No response from server (timed out), new attempt (#1) Received response from the server in 3516 milliseconds Reply packet code=3 id=3 length=20 Response: Access-Reject ------------------attribute dump---------------------- 

Next, you'll need to test accounting packets. The old standard for RADIUS accounting used port 1646. Change the port number in NTRadPing accordingly , and select Accounting Start from the Request Type drop-down list box. Make sure the root password is correct again, and send your request along. The response should be similar to the following:

 Sending authentication request to server 192.168.1.103:1646 Transmitting packet, code=4 id=5 length=38 Received response from the server in 15 milliseconds Reply packet code=5 id=5 length=20 Response: Accounting-Response ------------------attribute dump---------------------- 

Finally, stop that accounting process by changing the Request Type box selection to Accounting Stop and resending the request. You should receive a response like this:

 Sending authentication request to server 192.168.1.103:1645 Transmitting packet, code=4 id=6 length=38 Received response from the server in 16 milliseconds Reply packet code=5 id=6 length=20 Response: Accounting-Response ------------------attribute dump---------------------- 

If you received successful responses to all four ping tests, then FreeRADIUS is working properly. If you haven't, here's a quick list of things to check:

  • Is FreeRADIUS running? Use

     ps -aux  grep radiusd 

    to determine whether the process is active or not.

  • Is FreeRADIUS listening on the port you're pinging? If necessary, start radiusd with an explicit port, i.e.,

     radiusd -p 1645 
  • Have you added your Windows console machine to the list of authorized clients that can hit the RADIUS server? Do this in the /etc/raddb/clients file.

  • Are you using the correct secret key? This as well is configured in the /etc/raddb/clients file.

  • Have you double-checked the locations of the group , passwd , and shadow files inside the radiusd.conf file? These locations are specified in the Unix section. Make sure they're not commented out and that the locations are correct.

  • Can FreeRADIUS read the group , passwd , and shadow files? If you're running FreeRADIUS as root, this shouldn't be a problem, but check the permissions on these files to make sure the user/group combination under which radiusd is running can access those files.

  • Is there any port filtering or firewalling between your console machine and the RADIUS server that is blocking communications on the ping port?

  • Is the daemon taking a long time to actually start up and print a ready message (if you're running in debugging mode)? If so, your DNS configuration is broken.

To assist in diagnosing your problem, you may want to try running the server in debugging mode. While operating in this mode, FreeRADIUS outputs just about everything it does, and by simply sifting through all of the messages it prints while running, you can identify most problems.

To run the server in debugging mode, enter the following on the command line to start radiusd :

 radiusd -sfxxyz -l stdout 

It should respond with a ready message if all is well. If it doesn't, then look at the error (or errors as the case may be) and run through the checklist above.

You can also check the configuration of FreeRADIUS using the following command:

 radiusd -c 

This command checks the configuration of the RADIUS server and alerts you to any syntax errors in the files. It prints the status and exits with either a zero, if everything is correct, or a one if errors were present. This command is also useful when you're updating a production server that cannot be down: if there were a syntax error in the files, radiusd would fail to load correctly, and downtime would obviously ensue. With the check capability, this situation can be avoided.



Radius
Radius
ISBN: 0596003226
EAN: 2147483647
Year: 2005
Pages: 89

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net