RADIUS
Ron McCarty Network access servers (NAS), often referred to as access routers, are becoming common replacements in the enterprise for stacks of standalone modems. While NASs can either centralize or distribute points of access, or points of presence (PoPs), as Internet service providers prefer to call the dial-in points, NASs do not provide a method of client profile management. A Remote Authentication Dial In User Service (RADIUS) server can centralize the client profile management. RADIUS allows an organization that has, for example, PoPs in Chicago, Dallas, and New York City, to manage a RADIUS server at the central office in Denver where the remote access specialist works. Of course RADIUS servers can be located at each site, and the central profile file can be transferred to the sites via remote or secure shell or ftp. (Because of the sensitivity of the connection profiles, secure shell is recommended.) RADIUS was originally developed by Livingston Enterprises (now owned by Lucent Technologies), and server software is available from numerous sources, both as open source and commercial products. RADIUS support has also been incorporated into many NAS and router products, with authentication server software residing on an associated server. This article covers the installation and basic configuration of the Ascend RADIUS server. The concepts shown here should be generally applicable to most RADIUS implementations, however. Ascend's RADIUS server is freely available from the company's ftp server and is fully compatible with Ascend's Maxen routers. The RADIUS server runs as a daemon under UNIX and listens on UDP port 1645. During the initial release of the RADIUS recommendations, Livingston chose port 1645 as the RADIUS port and 1646 as the RADIUS accounting port. Unknown to Livingston, port 1645 had previously been assigned to datametrics and 1646 samsg-port, so Livingston corrected this mistake in RFC 2138. However, Ascend still refers to ports 1645 and 1646, and I will use port 1645 here as well. RADIUS Basics A RADIUS server does not actively poll the NASs, but rather listens for requests. The NAS acts as a RADIUS client to authenticate the dial-in user. Upon receiving a call, the Max will use the shared secret to send enough user identification information to authenticate the call (caller ID, PAP password, CHAP MD5 digest, or some other authentication method supported). If authentication is authorized, the Max will connect the user and if necessary start protocol negotiations. This is simplified view of the process. For a detailed description of the RADIUS operation refer to paragraphs 2, 2.1, and 2.2 of RFC 2138. Also take a look at the resources listed in the sidebar, "Resources". To maximize uptime, at least two RADIUS servers should be used to provide redundancy. Ascend Maxen are not configured with primary and backup RADIUS servers, but rather are cycled through when a response is not received in the time you specify. The type of connection made between the remote client and NAS can support network protocols such as IPX, TCP/IP, or AppleTalk, or even custom applications based upon terminal server features directly supported by Ascend routers. I am only covering PPP with TCP/IP. Various forms of HDLC and SLIP are supported, but PPP, because of the Internet's growth, is now the standard for remote access. All modern operating systems as well as routers support PPP. If you need support for HDLC, SLIP, or other line protocol, refer to the Ascend RADIUS Guide. It is available in PDF or postscript format at:
ftp://ftp.ascend.com/pub/Software-Releases/Doc/Radius/ If you cannot create a connection profile to meet your needs, you can also ask for help on the Ascend Users' mailing list. Who Should Use RADIUS If you have more than one Max router or more than 10 users, it probably makes sense to manage the connection profiles with RADIUS. This gives you central control for management and backup purposes and requires very little configuration on your Maxen, likely a very static configuration - just the IP Address, gateway, telnet passwords, and security and authentication configuration. With many users, a text file is much easier to manage than profiles on the router itself. The Ascend RADIUS server is available in C source and supports the following platforms: HP-UX, SCO UNIX, IBM AIX, SunOS, Sun Solaris, UNIXWARE, BSDI, Linux, and SGI IRIX. Check http://www.ascend.com/faqs/22/343.html for a current list of supported platforms. If your platform is not listed, ask the Ascend User mailing list to see if someone has a Makefile and/or modifications for your OS. I will discuss the BSDI 2+, Solaris 2.x, and RedHat Linux 5.1 installation here; however, with the exception of compilation, everything covered here is UNIX platform independent. I recommend the following steps for deciding how you want to implement RADIUS as part of your system architecture. Start by subscribing to the Ascend User mailing list. You can subscribe to the list by sending an email to ascend-user-request@bungi.com with the text subscribe in the body of the message. Then, read through RFC 2138, titled "Remote Authentication Dial In User Service (RADIUS)" to get a feel for RADIUS. Don't get bogged down in the technical details - RFCs are written with a developer slant - we mere mortals generally use them to fight insomnia. The background information will be helpful, but the actual implementation process is relatively simple, as we show here. First, we need to add radiusd to the network services file. Add:
radius 1645/udp radiusd to /etc/services. The use of port 1645 is incorrect, as mentioned previously, but I will use it in my examples. Download the source via anonymous ftp from:
ftp://ftp.ascend.com/pub/Software-Releases/Radius/Current/ The current version at the time of writing is RADIUS-980618.tar.gz. Place the source in the standard directory on the UNIX box where the RADIUS server will be running. I will use /usr/local/src/ here, but follow local policy. Uncompress the tar archive:
gunzip RADIUS-980618.tar.gz Untar the source:
tar xvf RADIUS-980618.tar This will create a directory named radius-980616 with the subdirectories CVS and radius-1.16-ascend. Within the radius-1.16-ascend directory, we have the following subdirectories: CVS, ascendd, doc, man1, raddb, and radiusd. Read through the README and INSTALL in the radius-1.16 directory. The README gives a quick breakdown of the directory structure, and the INSTALL file is a brief overview of the installation procedure. CVS - The CVS directory is used by programmers and the revision control system. We can ignore this directory. ascendd - This is the source code directory for the Ascend version of the RADIUS server. This is the directory we are interested in. doc - The doc directory has the drafts for the RADIUS and RADIUS accounting standards, but much more interesting is the ascend.doc file, an early draft of the Ascend RADIUS guide. man 1 - The man1 directory contains the man pages for the users file and the builddbm utility. The builddbm utility is necessary for systems using the UNIX DBM support, which this article doesn't cover. rad db - The raddb directory contains the dictionary file appropriately named dictionary. This file is used by the RADIUS serve to parse the connections file (users) into a form the RADIUS server, radiusd, can work with. The raddb directory also contains an example users file, which contains sample profiles, and a sample clients file, which contains a list of authorized NASs and their shared secrets. rad iusd - This directory contains the original Livingston source, commonly referred to as the reference source, since it was the code used for the Ascend radiusd. Now we need to make a few decisions: Should the radiusd run as root or as its own user? Despite what Step 6 in the INSTALL file says, the daemon can run as a non-root user. This has the advantage of allowing the administration to be delegated to a non-root account holder, as well as minimizing any future security threats that may be found. These examples assume you are running the daemon as user "raduser" and that this user's primary group is "radgroup". If the admin managing the radius server will be making changes to the connection profiles in the users file as root, but the process will run with the raduser ID, then the raduser account can also be further limited by not granting a shell account to the raduser. Create the user and group if you will run the daemon as a non-root user. Now we compile the source. gcc is the recommended compiler; however, check the current Makefile for system compiler support (such as cc for SunOS) if you haven't installed gcc. cd into the ascendd directory:
cd ascendd< Make a copy of the original Makefile in case you need to refer to it later. For example:
cp Makefile Makefile.orig The Makefile is well documented, but not completely logical. When you first read the Makefile, you may be tempted to remove the comments (marked with #) in front of the entries for your operating system at the top of the Makefile. These entries are actually documentation on what you should activate. So, let's use them as documentation. Here is the information for three systems covered here: Solaris:
# Solaris with gcc: # CFLAGS= -O -Dsys5 -DSOLARIS # (Add -D_SVID_GETTOD to CFLAGS for Solaris 2.1 - 2.4) # CC= gcc -ansi # add LIBS= -lnsl -lsocket BSDI:
# BSDI: # CC= gcc # Note: cannot use -ansi on some versions # Linux:
# Linux: # add -Dsys5 to CFLAGS These entries tell us which compiler to use, which compilation flags to apply, and which libraries to activate. Unfortunately, the Linux settings are not correct for RedHat Linux 5.0 and later (see http://www.ascend.com/faqs/22/1347.html). We'll correct as we go. Jump to the section in the Makefile titled "Pick your compiler". As noted above, cc = defines your compiler. If you are using Solaris, then the entry is:
CC= gcc -ansi # set the GCC compiler to ANSI mode The documentation says to use the -ansi parameter for Linux as well, but as Ascend points out in http://www.ascend.com/faqs/22/1347.html, this is no longer the case. If you are using Linux or BSDI, comment the above entry out and remove the # sign in front of this entry:
CC= gcc # set the GCC compiler for BSDI and friends We've now defined which compiler to use. We need to make similar entries for the compiler flags. In the section called "pick your compiler flags", comment out the standard SunOS by placing a # symbol in front of the entries:
#CFLAGS= -O -DNOSHADOW -DOSUN -DBINARY_FILTERS -DASCEND_SECRET -DASCEND_LOGOUT $(AUTH_SERVERS) and remove the appropriate comment for your OS: BSDI:
CFLAGS= -O -DNOSHADOW -DBSDI -DBINARY_FILTERS -DASCEND_SECRET -DASCEND_LOGOUT $(AUTH_SERVERS) Solaris:
CFLAGS= -O -Dsys5 -DSOLARIS -D_SVID_GETTOD -DBINARY_FILTERS -DASCEND_SECRET -DASCEND_LOGOUT $(AUTH_SERVERS) Linux:
CFLAGS= -g -Dsys5 -DNOSHADOW -DBINARY_FILTERS -DASCEND_SECRET -DASCEND_LOGOUT $(AUTH_SERVERS) And now we configure the libraries, once again correcting for the Linux differences if appropriate. Comment out:
#LIBS= -lnsl $(AUTH_LIBS) # use this for SunOS And add: BSDI:
LIBS= $(AUTH_LIBS) # use this for Linux, BSDI and friends Solaris:
LIBS= -lnsl -lsocket $(AUTH_LIBS) # use this for Solaris 2.x Linux:
LIBS= -lcrypt $(AUTH_LIBS) # use this for FreeBSD Save the Makefile, and start the compilation:
make The sources are well tested, so if you receive compilation errors, check your Makefile first. If you cannot find the problem, post a description of the problem, the error reported, your Makefile, RADIUS version, and your gcc version to the Ascend Users mailing list. Typically, responses are posted within a day. The sidebar "Troubleshooting and Other Tips" gives you some good starting points for troubleshooting NAS environments. Once the RADIUS server compiles cleanly, we set up the directory structure. The daemon itself can be placed where you deem appropriate. /usr/local/bin/ or /usr/local/sbin/ or /usr/local/radius/bin/ and /etc/raddb/ are often used. Copy the radiusd to the directory. We'll be using /etc/raddb , so let's create the directory:
mkdir /etc/raddb/And set the rights:
chmod 700 /etc/raddb/ Now copy the daemon into the directory (assuming we're still in the source directory):
cp radiusd /etc/raddb/ Assuming we are running the daemon as raduser, we should set the suid and rights appropriately:
chmod 4500 /etc/raddb/radiusd Copy the clients and dictionary file into /etc/raddb.
cp /usr/src/local/radius-980618/radius-1.16-ascend/raddb \Or get the most recent copy of the Ascend dictionary file from:
ftp://ftp.ascend.com/pub/Software-Releases/Radius/Current/dictionary and place it in your raddb directory. This file is a newer version than the dictionary distributed with the RADIUS source. Next, we clean house again:
chmod 400 /etc/raddb/dictionary chmod 600 /etc/raddb/clients Create an empty users file and logfile:
touch /etc/raddb/users touch /etc/raddb/logfile and set the rights approriately:
chmod 600 /etc/raddb/users chmod 600 /etc/raddb/logfile The two files that must be protected at all costs are the clients and users files. The clients file lists the authorized NAS servers as well as the shared secrets. The users files contains the users profile information such as CHAP username and password. These should never be group or world readable or writeable! Now that we have everything in the /etc/raddb/ directory, we can change the owners and groups to raduser and radgroup:
chown -R raduser:radgroup /etc/raddb/ Now we can create a sample remote client for testing in /etc/raddb/users. Open /etc/raddb/users with your editor and add the roadwarrior1 profile given in the sidebar, "Users Example". We're assuming your NAS has the IP Address 192.168.1.1 with a Netmask of 255.255.255.0 for these examples, and the dial-in client has 192.168.1.25 with a Netmask of 255.255.255.255 (single IP address). The "Important IP Addresses for the Example" sidebar lists all the addresses we are using. We will cover the example in detail later. We need to tell the RADIUS server that maxAC is authorized to make RADIUS queries. Open /etc/raddb/clients. Remove the entry:
pipeline testing123 from the clients file and enter:
192.168.1.1 Cannot32guessiT The 192.168.1.1 is the IP Address of the Max router we wish to authenticate for, and the secret-pass should be a pass phrase that is not easy to guess. You can also use a DNS name instead of the IP address, but an authentication request would fail if the system where the RADIUS server was running could not resolve the name of the NAS. Add radiusd to your startup script. On Solaris and Linux use System V startup mechanism (i.e., /etc/rcXd/) and on BSDI, the /etc/rc.local. Now we can start the daemon:
/etc/raddb/radiusd & Now configure the Max(en) using a telnet session or direct connection to the Max's serial (management) port to authenticate using RADIUS. The setting is in:
Ethernet->Mod Config->Auth Set the authentication to RADIUS and enter the IP address and UDP port of your RADIUS server. For this example, we would enter 192.168.99.1 and an Auth Port of 1645. At this time, you can also configure the RADIUS timeout - this is how long the NAS will wait for a reply before asking the next RADIUS server. Three seconds is a good setting. Now let's go through the connection profile and take a closer look at the profile for "roadwarrior1". The format for the connection profile is very important. I'll quote the format defined "users-file-syntax.1" in the man1 directory in the source tree: Comment lines start with a '#' character at column one and extend to the end of the line. User records consist of a 'first' line followed by the 'rest-of-record'. The rest-of-record is either a blank line, or a sequence of zero or more 'subsequent' lines followed by a 'final' line. A 'first' line has a non-'#', non-space, non-tab character at column one, followed by zero or more non-space, non-tab characters, followed by one or more spaces or tabs, followed by an attribute list (*without* a trailing comma), followed by a newline. A 'subsequent' line has a space or tab in the first column, followed by zero or more spaces or tabs, followed by an attribute list, followed by a comma, followed by a newline. A 'final' line is identical to a 'subsequent' line except that there is no trailing comma. Visually scanning the rules will allow you to notice errors more quickly than mentally going through them. Let's now decipher the attributes and their values. The first line:
roadwarrior1 Password = "No3Guess2Here" defines the CHAP username (or PAP, if PAP is allowed on the Max) and secret. The next line:
User-Service = Framed-User, defines the type of service to allow for this user. For PPP connections, the value will always be "Framed-User". Other possibilities are "Login-User" for implementing a terminal server, and "Dialout-Framed-User" for outgoing calls. The next line:
Framed-Protocol = PPP, defines the protocol the user will be using. As mentioned, we are only covering PPP. Other possibilities are COMB, FR, EURAW, EUUI, and MPP. We must now define the dial-in client's IP address and netmask:
Framed-Address = 192.168.1.25, Framed-Netmask = 255.255.255.255, Notice the "Framed-Netmask" is set to all ones. This defines a single address, not a subnet. This is a common configuration for single dial-in PCs and workstations. Now we have:
Ascend-Metric = 1, This is a cost associated with the route to the dial-in client and can be used in distance vector routing protocols such as Routing Information Protocol (RIP). Here's another entry for routing protocols:
Framed-Routing = None, This entry tells the NAS how to handle RIP with the remote client. For example, the NAS can just broadcast RIP updates and not allow any updates to be sent from the client to local networks. We've chosen "None", because we are not using RIP. And now the final entry:
Ascend-Idle-Limit = 300 This entry simply defines the number of seconds the NAS should wait before disconnecting the client due to inactivity. Use costs of the line and client inconvenience to determine the best inactivity timeout. If you're paying for expensive long distance calls then you don't want to keep the line up any longer than necessary. At the other extreme, you don't want to kick your modem users off after one minute, since a modem needs several seconds to connect. Although this connection profile seems quite simple, it will meet 95% of single address dial-in clients. This profile works with pppd (UNIX), Windows 95 and NT, and most router's PPP support. At this point you can configure the client to dial in to the NAS. Let's move on to a SOHO connection. Here we wish to connect a remote router that has been assigned an address of 192.168.2.1 with a netmask of 255.255.255.0 and is the gateway for the 192.168.2.0/24 network. The sidebar "Users Example" shows the soho profile. As you can see, there is nothing too special about this entry - just a different IP Address and netmask. Let's look at a dial-out connection profile so that if someone from our site initiates traffic, the Max will dial out to the SOHO router (soho-out in the sidebar). Let's cover the new attributes and parameters. The name "soho-out" is the naming convention for dial-out profiles. The password "ascend" is not really a password, but rather a placeholder for the parsing and is required here. The Ascend-Dial-Number = "5551212" tells the Max which number to dial to connect to soho-out. Ascend-Data-Svc = Switched-64K defines the bearer rate for ISDN. If you only have 56K ISDN, then use 56K here. If you have the digital modem module from Ascend, you can also use "Switched-modem" for an analog call. If you've studied the RFCs for RADIUS, you may wonder how this profile works, since the NAS asks for authentication verification and the RADIUS server does not push any information to the NAS. How does the Max know to use this profile to contact the SOHO router? Actually, we're missing a routing entry that the Max gets during its initial connection with the RADIUS server:
route-maxAC-1 Password = "ascend" User-Service = Dialout-Framed-User
Framed-Route = "192.168.2.0/24 192.168.2.1 1 n
soho-out"
This routing entry will be downloaded by maxAC when maxAC boots or when the admin updates the routing entries with the menu item "update remote configuration" ("Upd Rem Cfg") on the router. Did you notice that there may be a weakness with this outgoing profile? We have not defined any "outgoing" authentication. Let's suppose the admin of the remote site does not trust the telco's caller ID or does not receive the caller ID, and we have to send a CHAP username and password. There are two attributes to cover this requirement:
Ascend-Send-Auth=Send-Auth-CHAP, Ascend-Send-Secret="Be2Careful", The NAS will then use its system name (maxAC) for authentication. If the remote admin requires another name, then you can use Ascend-Authen-Alias to send another name. The sidebar "Users Example" gives a complete listing of all the profiles we've created. Closing the Circle I cannot cover all the possibilities you may encounter, but I have covered RADIUS installation and configuration and the two most common scenarios. I hope this article has given you a jump start on RADIUS. Other areas of interest you may wish to investigate are Radius Accounting (RFC 2139), caller ID authentication, callback (Maxen support Ascend Caller Identication ID and MS callback), virtual private networking, IPX networking, address pools (especially if you are using officially assigned addresses), call and data filters, Multilink PPP, and UNIX ("Berkeley") DBM support for the users database. I have also not covered any of the security aspects involved in dial-up networking. Be sure to follow the security guidelines supplied in your Max documentation and integrate the system in accordance with your security guidelines and with assistance from your firewall administrator(s). You do not want to pierce wholes in your security, and you definitely want to minimize the risks involved.
About the Author
Ronald McCarty received his bachelor's degree in Computer and Information Systems at the University of Maryland's international campus at Schwaebisch Gmuend, Germany. After completing his degree, Ronald McCarty started his network career as network administrator at the Schwaebisch Gmuend campus. Ronald McCarty currently works for FreiNet GmbH, an XLink ISP PoP in Freiburg, Germany. He spends his free time with his two best friends in the world: his daughter, Janice, and his wife, Claudia.
|