| [ Team LiB ] |
|
5.2 Installing FreeRADIUSAt 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.
Commonly, the following locations are used when installing a RADIUS product (these practices go back to the Cistron RADIUS server):
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 FileFirst, 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
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 FileNext, 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.
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 FileIf 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 port—which 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 FileProgressing 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 FileLet'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 FileFreeRADIUS 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 FileThis 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 SetupOnce 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 To do a quick test, follow these steps:
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:
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.  |
| [ Team LiB ] |
|
