RADIUS

Bill Moran <wmoran@potentialtech.com>

Update

Well, it was March of last year when I wrote the first of my articles about dial-in services. Since then, a lot has happened, and in the process the follow-up articles that I had promised never got finished. Now, after quite a while, a little prompting has convinced me to finally finish the next one.

RADIUS

What is RADIUS?

RADIUS stands for Remote Authentication Dial-In User Service. I don't know about you, but it sure sounds like they came up with the name "RADIUS" first, and figured out what it stood for later.

It's purpose is to supply information and authentication for multiple dial-in servers. If you only have a single dial-in server then you probably don't need the complexity of RADIUS. However, if you want to provide dial-in services to clients in more than one area code, you'll probably have to rent "points of presence" from the phone company, and the phone company will expect you to have a RADIUS server.

Here's how it works. Let's take a fictitious ISP located in Columbus, Ohio. This ISP wants to provide dial-in services to everyone in Ohio, and maybe expand even further some day. It would be impractical to have all their modems located in Columbus, since most people won't sign up with Internet service if they have to dial long-distance. So the ISP sets up a RADIUS server, located in the main office in downtown Columbus. It then installs 100 modems in this office and configures them all to use the RADIUS server to authenticate. There's also a branch office in Zanesville, so they instal 20 modems there and configure all of them to authenticate off the RADIUS server in the Columbus office. They also want to serve customers in the Cleveland area, but there's no office there. So they contact the phone company in Cleveland and set up a deal to lease 100 modems in Cleveland that will authenticate from the RADIUS server located in Columbus.

The advantages to this are obvious, new customers are added to a single server and are then able to dial-in to whatever phone number is closest to them. These users can also roam all over Ohio and still be able to dial in to their ISP to get their email, using a local number.

Radius also has an accounting system built in that keeps track of who dials in when and from where. For those like me who like to keep track of who's using their services, the accounting is an important tool.

Setting up RADIUS

Radius is a client-server protocol, so one of the first things to do is set up a RADIUS server. This is actually very painless (if you know what you're doing) so I'll speed through the setup of an Ascend-RADIUS server on FreeBSD. There are other RADIUS servers available (most notable FreeRADIUS) and the configuration will be very similar.

For this document I want to define some terms, since it will alleviate some confusion before it starts.

A RADIUS Server is the server component of the RADIUS protocol. It holds all the authentication information and delivers this information to RADIUS clients when they request it. It also maintains accounting logs that contain anything reported by any number of RADIUS clients.

A RADIUS Client constitutes the client end of RADIUS. It authenticates dial-in users by checking their passwords against the RADIUS server, and reports what has happened to the RADIUS server so the server can log it. These clients are called NAS in RADIUS-speak. NAS stands for "Network Access Server" which seems an odd name for a "client". Remember that the RADIUS client is also a ppp server, and as such is truly serving out network access. The client may be a BSD or Linux server running pppd or a dedicated piece of hardware from a company such as Cisco.

A dial-in user is the person who wants to dial in to get access to the Internet or other network. This is the user who uses the Internet for web-browsing and email.

Step 1: Install the server software

The Ascend-RADIUS server is part of the wonderful FreeBSD ports collection, so the installation is very painless. Simply enter the following:

cd /usr/ports/net/ascend-radius;make all install

and wait for the system to download, build and install the software. Make sure you're root before doing this. If you're so lazy that even the ports system isn't fast/easy enough for you, there's a precompiled package for Ascend that can be downloaded and installed or installed through /stand/sysinstall

For some reason, the Ascend-RADIUS port doesn't install a startup script. This is easy enough to remedy, though. In my case, I simply created a file /usr/local/etc/rc.d/radiusd.sh containing:

#!/bin/sh
setenv HOST=radiusserv.mydomain.com
/usr/local/sbin/radiusd.dbm

Make sure this file has execute permissions. (chmod +x /usr/local/etc/rc.d/radiusd.sh will do the trick).

Step 2: Set the correct port

You may never need to do this step, but it's important to know about it in the unlikely case it becomes an issue.

I don't know the exact history, but apparently, many companies began implementing the RADIUS protocol before it was even completed. When the specifications were finalized, IANA had determined that RADIUS would use udp ports 1812 and 1813. Unfortunately, the ISP community had already been using udp ports 1645 and 1646.

Most modern RADIUS programs are configured to use the correct ports, but it's always possible that you'll come across hardware or software that's using the old ports. You'll have to determine whether you can fix the offending hardware/software to use the correct ports, or whether you'll have to modify your RADIUS server to use the old (unofficial) ports.

To change which ports Ascend uses, modify /etc/services. In FreeBSD, the lines for the old ports are already there, but commented out. If you uncomment the 1645/1646 lines, be sure to comment the 1812/1813 lines or you'll have trouble.

Step 3: Check your firewalls

If you're like me, you're paranoid and have packet-filtering firewalls everywhere. Make sure that they're configured properly to allow udp traffic on the correct ports to the RADIUS server.

Step 4: Configure the server to accept clients

A RADIUS server only talks to clients that it knows about. It uses an encryption scheme that prevents snoopers from seeing what's going on between the server and client, and also prevents spoofing. The encryption requires the use of a "shared secret" which means that both client and server must be provided with the encryption key. On the server, your client configuration is in the file /usr/local/etc/raddb/clients. The format is a simple white-space delimited list. The first column is the name or IP address of a RADIUS client. The second column contains the shared secret. New records start on a new line. For example:

10.4.3.2       secret
10.200.220.157 evenmoresecret
10.15.17.21    youllneverguessthis

In this example file we have 3 clients. 10.4.3.2 uses the key "secret" while 10.200.220.157 uses the key "evenmoresecret" and 10.15.17.21 used the key "youllneverguessthis". Some important things to remember:

• The secret must be the same on the client as on the server. Be sure to transfer the secret to the client by a secure means, use encrypted email or take it there yourself. If someone can get your secrets, they can sniff RADIUS traffic for passwords and steal service from you.
• Apparently some clients have a limit on how many characters the secret may be (although I've yet to encounter this) so make sure you're not overdoing it. Check the documentation for the clients you're using to see if there are any such limits.
• Permissions on this file should be 600 (read/write by owner only) and the file should belong to root.wheel. This is a pretty important file that must be kept secure, so make sure it's protected on both the server and the clients.
• Make sure this machine is secure. If you use your last name as the root password and someone guesses it, they can read your secrets file and (once again) steal service from you.

Step 5: Set up accounting

For each "client" you created in step 4, you should create a directory under /var/log/radacct. The RADIUS server will store account information here for you about what occurs. Dial in times, data transmitted and (depending on the capability of your clients) even caller ID numbers can be stored. In this case we want to create three directories: /var/log/radacct/10.4.3.2, /var/log/radacct/10.200.220.157 and /var/log/radacct/10.15.17.21. If you have any questions about who is dialing in on these lines, or anything else, check the "detail" file the RADIUS server maintains here. Another important note is that these files can become large very quickly if the server sees a lot of activity. In my case, I've configured newsyslog(8) to manage these for me by adding some lines to /etc/newsyslog.conf.

/var/log/radacct/10.200.220.157/detail 600 12 * $M1 Z
/var/log/radacct/10.4.3.2/detail       600 12 * $M1 Z
/var/log/radacct/10.15.17.21/detail    600 12 * $M1 Z

These rotate the logs once a month, and keep one year's worth of logs. See the man page for newsyslog(8) for details.

Step 6: Configure the dial-in users

I've left this step for last for a good reason. Steps 1 through 3 should only need done once when you first set up your RADIUS server. Steps 4 and 5 will only need done when a new RADIUS client is added to your network.

But this step needs done every time you add or remove users from the network, or whenever you want to change the permissions on what services these users have access to.

# User Joe Smith from Columbus
joesmith Password = "letmein"
 User-Service = Framed-User,
 Framed-Protocol = PPP
# User Tom Jones from Zaynsville
tomjones Password = "mydogsname"
 User-Service = Framed-User,
 Framed-Protocol = PPP

This would allow dial in access, or PPP, to two users, "joesmith" with password "letmein" and "tomjones" with password "mydogsname". These are the user names and passwords that allow the end user access to the Internet when he dials up from home.

The format deserves some special attention. Other servers may have a different format for the users file, but since we're using Ascend in this example, I'll go into some of the peculiarities of Ascend.

The file consists of comments (which start with a # and are ignored by Ascend), blank lines and records.

Records are composed of an arbitrary number of lines. Each line is composed of a single line, terminated by a newline and multiple lines are separated by a comma, so the end of a record is indicated by a line with no comma after it.

Except the first line which establishes the record. This line is always the username followed by some attributes. There is no comma between this "start of record" and the second line, but all lines thereafter must be comma separated. And all lines after the first line must start with whitespace (either a space or tab) while the first line must not.

Let's look at an example of a more complicated users file:

# Record for Joe Smith that
# allows PPP login
joesmith Password = "letmein"
 User-Service = Framed-User,
 Framed-Protocol = PPP

# Tom Jones is allowed a telnet shell
tomjones Password = "mydogsname", User-Service = Login-User
 Login-Service = Telnet

Interesting, isn't it? More detailed information on the format of the users file can be found in the documentation, which is installed in /usr/local/share/doc/ascend-radius/ by default. I see no reason to duplicate that documentation here, but I feel it important to state 2 things:

1. There are a lot of directives that can be assigned to a given user login. Which ones you use will depend on your particular needs.
2. The formatting of this file is very picky. If something isn't working correctly, one of the first things to do is to carefully check the syntax of your users file to make sure you haven't broken any rules.

Once your users are added to the file, it should be compiled into a database that the RADIUS server can quickly search when information is requested. While this is not necessary, it's a good idea (especially if you have a lot of users). Note that I do not cover running Ascend-radius without creating a users database in this article, if you would like to run Ascend without compiling a users database, please consult the Ascend documentation.

This step is very simple, simply run the following command:

cd /usr/local/etc/raddb; builddbm

If you don't get any errors, the creation was successful. Take a look and you'll see that the file /usr/local/etc/raddb/users.db was created. You can now start the Ascend RADIUS server. Simply typing /usr/local/sbin/radiusd.dbm as root will do the trick.

When the Ascend server is running properly, there will be two processes. One of them services authentication requests, while the other records data that is send by the RADIUS clients. See the documentation on your particular NAS to control what is logged, the Ascend server simply logs everything that it is sent.

That should get you up and running with a RADIUS server. Obviously, there are other things that could be done. In a real-world situation, you'll probably want at least two RADIUS servers so clients can fail-over if the primary crashes or otherwise becomes unavailable. There's also the configuration of the clients, but these topics are beyond the scope of this particular article.

That's all for now, I hope this information is useful.