RADIUS, the Remote Authentication Dial-In User Service, was originally developed by Livingston Enterprises for its PortMaster series of Network Access Servers. Merit Network, Inc., and Livingston have subsequently made several major changes and improvements in the RADIUS software. Primary development work on RADIUS at Merit and the University of Michigan was performed by William Bulley and Allan Rubens.
Merit makes the RADIUS software available for anonymous FTP, and provides consulting services to Merit members and affiliates who are using the software to support the shared MichNet dial-in program. RADIUS consulting is not available to affiliates who are running the software to support private dial-in that is not part of the MichNet shared dial-in infrastructure.
Authentication for Dial-in
RADIUS, which is both a software program and a detailed communications protocol, plays an important role in providing dial-in services to MichNet users around the state. Users have long been able to access MichNet by dialing local numbers in many Michigan cities. The local dial-in lines are owned by organizations affiliated with Merit- organizations in education, research, industry, and government-and are shared among MichNet's users. Use of this shared resource has increased dramatically over the years; as a result, more and more users are encountering busy signals when they dial in to MichNet.
Working with the organizations that own and operate the dial-in lines, Merit is instituting a new dial-in policy that will reduce the number of busy signals, while still making it possible for users to access MichNet's dial-in facilities from cities statewide. The new policy:
RADIUS makes it possible to implement the Merit policy by identifying users as they dial in to MichNet and determining what they can do on the network, depending on their affiliation. RADIUS provides the following services:
Each Merit organization will eventually be limited to a maximum number of simultaneous dial-in sessions that it is allowed to authorize. If these limits are set appropriately, there will be a direct relationship between the number of dial-in sessions that are allowed and the number of sessions the shared dial-in infrastructure can support. Busy signals may still occur, but should be greatly reduced.
UserIDs for Individuals and Groups
Under the new policy, dial-in users can authenticate using one of two types of userIDs: individual and group. Individual userIDs, such as jane.doe@calvin.edu, give users certain privileges and limits during their dial-in sessions, depending on the policies established by the organization providing the userID-Calvin University, in this case. For example, users might be able to log in at a certain time of day for a certain length of time, or be able to access a particular set of network resources.
Some organizations may also choose to make group userIDs available, as a way to open up dial-in services to a broader audience without the need to provide individual userIDs to large numbers of people. An example of a group userID would be guest@gotham.lib.mi.us. Such a userID would be available to any user who wanted to access the Gotham public library, and would use a well known password such as "anonymous."
NASs, Helpers, and Servers
When a user dials in to a MichNet Network Access Server (NAS), the NAS uses the RADIUS protocol to send a message containing the user's userID and encrypted password to one of several MichNet "helper" systems located around the state. The helpers are UNIX systems running the RADIUS server software. Each helper is configured to know how to contact the RADIUS server at the user's home organization in order to authenticate/authorize the user's session. The servers at Merit member/affiliate home organizations and the helpers run more or less the same set of RADIUS software.
Shared Secret
Several important security features are built into the RADIUS protocol. To keep passwords secure as they are transmitted from the NASs to the RADIUS servers, a code called a "shared secret" is used to encrypt the user's password. The receiving end unencrypts the password using its knowledge of the shared secret, and uses the real password value to check the user's credentials against either its UNIX password database, located in the /etc/passwd file, or against a remote Kerberos server, or by contacting a RADIUS-modified TACACS server. For more information, see the "Configuration" section later in this document.
As of this writing, RADIUS builds and runs correctly on the following platforms:
With a modest amount of work, RADIUS can also be made to run on other versions of UNIX, and on Novell NetWare LANs. For more information, contact the Merit staff by sending e-mail to radmaster@merit.edu.
Follow the steps below to transfer the RADIUS software to your system and decompress it.
1. Download RADIUS via anonymous FTP. Choose the latest version of RADIUS with the suffix .tar.Z
2. Enter the following command at the shell prompt ( % ) to uncompress the file:
% uncompress radius.tar.Z
3. To create a directory hierarchy for the RADIUS files, enter the following "tar" command:
% tar -xf radius.tar
The following RADIUS files will now be on your system in the directory from which you ran the tar command:
README Makefile INSTALL README.Merit TUTORIAL tarlistThe following RADIUS subdirectories will now be on your system:
./raddb(administrative files)
authfile dictionary clients users
The files authfile, clients, and users are templates, or sample files. Most users will need to customize the authfile and the clients file for their RADIUS installation. It will rarely, if ever, be necessary to customize the users file. See Configuration and Installation later in this document for more information.
./src (source files)
afs_stringtokey.c md5.h tacacs-routines.c attrprint.c mit_stringtokey.c tacacs-server.h auth_fun.c prot.h tacacs.h builddbm.c radcheck.c tacacs_nui.c dict.c radius.h ua_vms.h id_to_key.c radiusd.c users.c includes.h radpass.c util.c krb_conf.h radpwtst.c xtacacsd.c krb_get_in_tkt.c sendserver.c md5.c syslog_vms.c./man (manual pages, known as man pages)
authfile.5 radcheck.8 builddbm.8 radiusd.8 clients.5 radpwtst.8 dictionary.5 users.5./doc (documentation)
draft-ietf-nas-radius-01.txt radius-desc.txt4. Use a text editor to edit the Server section of the file Makefile, which contains information about the type of RADIUS implementation you want to build. The types currently are: RADIUS (the default), MIT Kerberos, AFS Kerberos, DBM, KCHAP, MNET, and TACACS. Each type is described further at the beginning of Makefile.
To select the desired type, remove the comment character ( # ) from the beginning of each line that describes that type. Be sure to replace the comment character in front of lines you don't want. You won't need to edit the file if you want to use the default.
5. For non-SunOS 4.1.3 machines, edit the operating system section of Makefile. Select the desired operating system by removing the comment character ( # ) from the beginning of each line that describes that system. Be sure to add comment characters in front of the lines of the default SunOS 4.1.3 section, for non-SunOS platforms.
6. To build the RADIUS server and the utilities, enter the following command from the directory from which you ran the tar command:
% make
7. Make sure your system has an /etc/shells file. This file lists, one per line, the full path name of the various shell programs available to normal users on your system. Examples are: /bin/sh, /bin/csh and /bin/ksh (but only one per line).
Follow the steps below to configure the RADIUS software.
1. Use a text editor to configure the file authfile for your site. This file contains a list of realm names that can be used to authenticate your users, along with the type of authentication to be used. (A realm is a collection of users who are authenticated by a particular site. For example, calvin.edu is a realm.) You will need at least one entry in the authfile for your site's host machine, the one on which you plan to run the RADIUS server.
Here is a sample authfile:
xyz.calvin.edu UNIX-PWFor a detailed description of authfile entries as well as configuration instructions, see the introductory comments in the authfile and the authfile man page.
2. Configure the clients file for your site. This file contains a list of client systems that are allowed to make authentication requests of your server, and their encryption keys (shared secrets). You will need at least one entry for your site's host machine, the one on which you plan to run the RADIUS server, and an additional entry for each of the Merit helpers (currently four) at various locations around the state.
The first field in the clients file is the client's IP address or Domain Name System (DNS) hostname. The second field (separated by blanks or tabs) is the shared secret, which is currently limited to fifteen (15) characters in length. Here is a sample clients file:
homeless.merit.edu sharedsecret1 homerun.merit.edu sharedsecret2 dogmatix.merit.edu sharedsecret3 getafix.merit.edu sharedsecret4You will need to coordinate the selection of a shared secret with the staff at Merit. Contact radmaster@merit.edu for more information.
For more information about the clients file, see the clients man page, the comments inside the sample clients file, and the README.Merit file.
NOTE: It is essential that users not be able to read the clients file.
Follow the steps below to install the RADIUS software.
1. Place the RADIUS executable radiusd, which handles requests for user authentication, into a well known directory, such as /usr/private/etc. Place the RADIUS configuration files (dictionary, users, clients, and authfile) into a similar place, such as /usr/private/etc/raddb. See the man pages for radiusd, dictionary, users, clients, and authfile for more information. You may want to alter your path environment variable at this point to include the path to the executables for the test utilities, radcheck and radpwtst.
2. Add an entry to the /etc/services file to assign a port to RADIUS. The default is UDP port 1645. For more information, see the radiusd man page.
1. Test your server by issuing the following commands. (This example assumes the RADIUS server and test utilities are on your path.)
radiusd -p 1646 -d
The choice of port 1646 is arbitrary, but is meant to steer clear of an already running RADIUS server that might be listening on the 1645 port.
2. If that test is successful, try to authenticate a test user as follows (with the radpwtst command typed on one line):
radpwtst -p 1646 -d <raddb-dir> -s <your-server-name> xyz@host
Password:
The host following xyz@ must be in your authfile and is, in this case, probably the same as <your-server-name> .
3. If that test is successful, kill the radiusd process to avoid confusion later.
4. To set up your server for production use, add a line such as the following to the /etc/inetd.conf file:
radius dgram udp wait root /usr/private/etc/radiusd radiusd
(This line is given as an example; RADIUS does not need to run as root.) This will cause RADIUS to run (if it isn't already running) whenever a RADIUS packet arrives on your machine, and will restart RADIUS automatically if RADIUS crashes. See the radiusd man page for more information. You must also send the HUP signal to the inetd process to inform it about your changes to the /etc/inetd.conf file:
kill -HUP
If you have questions about RADIUS or would like to register your server with Merit, contact the Merit staff by sending e-mail to radmaster@merit.edu