#

# Installing and Starting RADIUS

This chapter describes how to install and start the RADIUS daemon.This chapter contains the following topics:

What is RADIUS?
What you need before you start
Installing the RADIUS daemon
Installing radipad for global IP pools
Configuring the MAX to use the RADIUS server
Vendor-Specific Attribute (VSA) support
Using SNMP to specify the primary RADIUS server
Starting the RADIUS daemon

## What is RADIUS?

Remote Authentication Dial-In User Service (RADIUS) is a protocol originally developed by Livingston Enterprises, and extended by Ascend Communications, Inc. Using the Ascend RADIUS daemon, you can perform these tasks:

- Exchange session authentication and configuration information between a Network Access Server (NAS) such as the MAX, and an authentication server.

- Carry accounting information from an NAS to a RADIUS server.

  A RADIUS server is the machine on which the RADIUS daemon is running.

## What you need before you start

To use RADIUS with the MAX, you need the following items:

- A UNIX workstation or PC to run the RADIUS daemon.

- A TCP/IP connection between the RADIUS server and the MAX.

## Installing the RADIUS daemon

To install the RADIUS daemon, follow these steps:

1. Use anonymous FTP to download the most recent RADIUS files from ftp.ascend.com.

2. Decompress (unzip) and separate (tar) the files.

3. Read the README file, installation instructions, and makefiles.

   The installation instructions on the Ascend FTP server always provide the latest information on installing RADIUS.

4. Use the appropriate makefile to compile the Ascend RADIUS daemon on your system.

   The keywords ACE, SAFEWORD, and UNIX are reserved words built into the Ascend RADIUS daemon for use with external authentication servers. You can replace these reserved words with other strings by editing the daemon's source file before compiling it.

5. Move the file called dictionary to /etc/raddb.

   This file is the Ascend RADIUS dictionary, and contains a list of all attributes that the RADIUS server supports.

   You must install the dictionary on your RADIUS server in the same directory as the Ascend RADIUS daemon, and it must have the same date as the Ascend RADIUS
   daemon. If you find a discrepancy in the dates between the daemon and the dictionary, download the latest dictionary file from ftp.ascend.com, and copy it into the same directory as the daemon.

   Note that the RADIUS daemon reads the dictionary when it starts up. If you update the dictionary file while the daemon is running, you must stop the daemon process and then restart it to make the new attributes available.

   For further information about the dictionary file, see Dictionary file.

6. Use a text editor to open the /etc/services file and add a line identifying the RADIUS daemon's authentication port.

   For example, enter this line:

       radius      1645/udp

   The port number you specify must match the port number specified by the Auth Port parameter in the Ethernet > Mod Config > Auth menu.

7. To enable the RADIUS host and the MAX to communicate on the IP network, make sure that you include the MAX unit's name and IP address in the /etc/hosts file on the RADIUS host or in the Yellow Pages database.

8. Create a file called clients in the /etc/raddb directory.

   The RADIUS server does not simply authenticate incoming calls. It must also authenticate the Network Access Server (NAS) from which it receives requests. The MAX is an NAS and a client of the RADIUS server.

   For the RADIUS daemon to respond to requests from the MAX, you must specify the MAX unit's name and password in the clients file.

   - For the name, specify the value of the Name parameter in the System profile.

   - For the password, specify the value of the Auth Key parameter in the Ethernet > Mod Config > Auth menu.

     For example, add a line to the clients file like this one:

         Ascend3      bXSAMpy

     The argument Ascend3 is the value specified by the Name parameter. The argument bXSAMpy is the password specified by the Auth Key parameter in the Ethernet > Mod Config > Auth menu. The name you specify must be resolvable on the IP network (through DNS, the Yellow Pages, and so on). Otherwise, you must specify the IP address of the MAX.

     If the accounting process of the daemon will be running on the same server as the authentication process (rather than on a separate host), the same password must also serve for the Acct Key parameter in the Ethernet > Mod Config > Accounting menu.

9. Create a file called users in the /etc/raddb directory.

   A user is a caller that connects to the MAX. The RADIUS users file contains security and configuration information for each user. The full set of information for each user is called a user profile.

   The MAX can authenticate an incoming call locally or through RADIUS. Local authentication occurs when the caller's name and password match a Connection profile stored in the MAX unit's memory. RADIUS authentication occurs when the caller's name and password match an entry in the RADIUS users file.

   For introductory information on the users file and its format, see Users file. For details on creating user profiles to carry out various tasks, see the remaining chapters in this guide.

10. Create the logfile in the /etc/raddb directory.

    RADIUS writes error messages to /etc/raddb/logfile. The Syslog daemon does not create the RADIUS log file, so you must create the file yourself.

## Installing radipad for global IP pools

You can use RADIUS to specify pools of IP addresses that a MAX can use to dynamically allocate IP addresses to incoming callers. By default, each MAX handles dynamic IP address allocation individually from a pool of addresses pre-assigned to each MAX. However, you can also set up your system to allocate IP addresses from a global pool of addresses that many units share. To do so, you must install radipad. Follow these steps:

1. Install radipad in the same directory in which you installed the RADIUS daemon.

2. Add the following lines to /etc/services on the hosts where both radipad and the RADIUS daemon reside:

       radipad    9992/tcp #RADIUS IP address allocation from global pools

   The port number 9992 is the default. You can change it as required.

3. Modify your startup script to start radipad when the system comes up:

          #
          # Start up radipad for remote users
          #
          if [ -f /usr/local/bin/radipad ]; then
                  /usr/local/bin/radipad; echo -n ' radipad'
          fi

   Multiple hosts can run the RADIUS daemon, but only one host on the network should run radipad. Radipad is the central manger for global IP address pools on a network.

   You must start up radipad manually the first time. To do so, you must be the user root.

For information on configuring global IP address pools, follow the instructions in Configuring global IP address pools shared by several MAX units.

## Configuring the MAX to use the RADIUS server

This section describes how to configure the MAX to communicate with the RADIUS daemon. For additional information on each parameter you set, see the MAX Reference Guide and the MAX Security Supplement.

Note: This section describes the basic configuration procedure. It does not cover how to configure RADIUS for accounting purposes. For information on setting up accounting, see Setting up RADIUS accounting.

1. Open the Ethernet menu.

2. Open the Mod Config menu.

3. Open the Auth menu.

4. Set the Auth parameter to RADIUS or RADIUS/LOGOUT.

   If you set Auth=RADIUS/LOGOUT, RADIUS keeps track of session logouts.

5. For each Auth Host parameter, specify the IP address of a RADIUS server.

   You can have up to three RADIUS servers on your network. One is the primary server. Two additional servers can serve as backups. If the primary RADIUS server fails, the MAX automatically contacts the secondary RADIUS server to authenticate a user.

   The MAX first tries to connect to Auth Host #1. If it receives no response within the time specified by the Auth Timeout parameter, it tries to connect to Auth Host #2. If it again receives no response within the time specified by Auth Timeout, it tries to connect to Auth Host #3. If the MAX unit's request again times out, it reinitiates the process with Auth Host #1. The MAX can complete this cycle of requests a maximum of ten times.

   When it successfully connects to an authentication server, the MAX uses that machine until it fails to serve requests. By default, the MAX does not use the first host until the second machine fails, even if the first host has come online while the second host is still servicing requests. However, you can use SNMP to specify that the MAX use the first host again. For details, see Using SNMP to specify the primary RADIUS server.

   You can also specify the same address for all three Auth Host parameters. If you do so, the MAX keep trying to create a connection to the same server.

6. For the Auth Port parameter, enter the UDP port number you specified for the daemon in the /etc/services directory.

   The MAX and the daemon must agree about which UDP port to use for communication, so make sure that the number you specify for the Auth Port parameter matches the number specified for the daemon.

7. To specify the number of seconds the MAX waits for a response to a RADIUS authentication request, set the Auth Timeout parameter.

   If the MAX does not receive a response within the time specified by Auth Timeout, it sends the authentication request to the next authentication server specified by the Auth Host parameter.

   By default, if authentication fails on a PPP connection because of a bad password or an authentication server timeout, the Ascend unit gracefully shuts down the PPP connection by sending an LCP-CLOSE request to the dial-up user. When Windows 95 (MSN) receives the LCP-CLOSE during authentication, it assumes a rejected password, and displays a message telling the user that his or her password is invalid. If authentication fails because of a RADIUS timeout, this message gives the user incorrect information.

   To specify that the Ascend unit simply hangs up a PPP connection on a RADIUS timeout without closing down cleanly, set Disc on Auth Timeout=Yes in the Answer profile. The resulting message to the user specifies that the network failed.

8. For the Auth Key parameter, enter the RADIUS client password exactly as it appears in the RADIUS clients file.

   The password is case sensitive.

9. Set the Auth Pool parameter to specify whether the MAX sends the IP address from pool #1 to the RADIUS server when it requests authentication.

   For information on the Auth Pool parameter, see Configuring accounting with dynamic IP addressing.

10. If you want to enforce CLID authentication for connections with Id Auth=Require, set Auth Req=Yes.

    This setting specifies that the MAX requires a response from the RADIUS server for CLID authentication. If the MAX makes a request to the RADIUS server for the caller's user profile and the request times out, the MAX rejects the call.

    If you set Auth Req=No and the RADIUS query times out the MAX accepts the connection, even though Id Auth=Require and the MAX has not verified the user's ID. This type of setup assumes that the MAX performs an additional level of authentication.

    If Id Auth=Prefer or Id Auth=Ignore, the MAX ignores the Auth Req parameter.

    For detailed information on CLID authentication, see Setting up CLID authentication.

11. To specify information about the host running the APP Server utility, set the APP Server, APP Host, and APP Port parameters.

    For more information, see Configuring the MAX to recognize the APP Server utility.

12. To configure the MAX to recognize a security-card authentication server, set the Password Server and Password Port parameters.

    For more information, see Configuring the MAX to recognize the authentication server.

13. To specify whether the MAX first checks for a local Connection profile when attempting to authenticate a connection, set the Local Profile First parameter.

    You can specify either Yes or No.

    - Yes indicates that the MAX checks for a local Connection profile, then a Password profile, and then a remote profile when attempting to authenticate a connection.

    Yes is the default.

    - No indicates that the MAX checks for a remote profile, then a local Connection profile, and then a Password profile when attempting to authenticate a connection.

14. Set the Sess Timer parameter (if Auth=RADIUS/LOGOUT).

    The MAX can report the number of sessions by class to a RADIUS authentication server when Auth=RADIUS/LOGOUT. The Sess Timer parameter specifies the interval in seconds in which the MAX sends session reports. You can specify a number between 0 and 65535.The default value is 0 (zero), which indicates that the MAX does not send reports on session events.

15. To specify the source port to use for sending a remote authentication request, set the Auth Src Port parameter.

    Specify a port number between 0 and 65535. The default value is 0 (zero). If you accept this value, the Ascend unit can use any port number between 1024 and 2000. You can specify the same source port for authentication and accounting requests.

16. Set the Auth Send Attr 6, 7 parameter.

    This parameter specifies whether the MAX sends values for the User-Service (6) and Framed-Protocol (7) attributes in Access-Request packets to the RADIUS server. While some RADIUS servers require these attributes in authentication requests, other RADIUS servers should not receive them.

    Set this value to Yes if you want to generate the appropriate values for attributes 6 and 7 for an incoming call and send them in authentication requests to the RADIUS server. For example, if you set Auth Send Attr 6, 7=Yes, the MAX sets User-Service=Framed-User and Framed-Protocol=PPP for incoming PPP calls. The default value is Yes.

    Set this value to No if your RADIUS server does not require attributes 6 and 7 in authentication requests.

17. Save your changes.

## Vendor-Specific Attribute (VSA) support

RFC 2138, Remote Authentication Dial In User Service (RADIUS), specifies methods of handling vendor extensions and of encrypting and decrypting the User-Password. The RFC-defined methods differ from the way Ascend has implemented these functions in the past. In the past, Ascend extended RADIUS operations by adding Ascend vendor attributes, such as Ascend-Xmit-Rate, and used its own Ascend algorithm for User-Password encryption.

The MAX supports RADIUS RFC-compliance for the Vendor-Specific Attribute (VSA) and the RFC-defined User-Password encryption algorithm. Ascend maintains backward compatibility by making VSA compatibility mode configurable. However, attributes of Type 91 or smaller are supported only in VSA compatibility mode. Attributes of Type 92 or higher are supported in both VSA compatibility mode and the default mode, which is compatible with older Ascend implementations.

### About the Vendor-Specific attribute

RFC 2138 defines the Vendor-Specific attribute (type 26), which encapsulates attributes introduced by vendors. The purpose of the Vendor-Specific attribute is to enable companies to extend RADIUS operations without leading to possible attribute collisions (two attributes with the same type number but different meanings).

The format of Ascend vendor attributes in a request or response is new. The older Ascend format for all attributes is as follows:

     0                   1                   2
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
    |     Type      |    Length     | Value ...	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

The format of the VSA (as defined in RFC 2138) is as follows:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Type      |  Length       |            Vendor-Id
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     Vendor-Id (cont)           | Vendor type   | Vendor length |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Attribute-Specific...
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

The Type of the VSA is 26. The Length is 8 or greater. Ascend's Vendor-Id is 529.

The Vendor Type, Vendor Length, and Attribute-Specific Value are the same as the Type, Length, and Value of the unencapsulated Ascend attribute found in the current dictionary. For example, the Type of the Ascend-Xmit-Rate attribute is 255. Because it is an integer, it has a Length of 6. The Value is the transmit rate of the connection. So, the fields of the VSA will specify the following values:

- Type = 26

- Length = 12

- Vendor-Id = 529

- Vendor Type = 255

- Vendor Length = 6

- Attribute-Specific Value = transmit-rate

Note: Some vendors have interpreted RFC 2138 to allow packing more than one vendor attribute in a single VSA. Ascend does not support this use. The MAX sends a single vendor attribute per VSA. If it receives a VSA that contains more than one vendor attribute, it recognizes the first vendor attribute and ignores the rest.

### Configuring the MAX for VSA compatibility mode

When you configure the MAX to support VSA, the MAX uses the Vendor-Specific attribute to encapsulate Ascend vendor attributes and uses the RFC-defined User-Password encryption algorithm.

When you configure the MAX not to support VSA, which is the default setting, the MAX does not send the Vendor-Specific attribute to the RADIUS server and does not recognize it if the server sends it. The MAX uses the Ascend algorithm when encrypting and decrypting the User-Password attribute, and the Ascend algorithm differs from the RFC-defined algorithm, because it does not null fill the password string to a multiple of 16 bytes before encryption, and the Ascend algorithm does not use the previous segment's hash to calculate the next intermediate value when the password is longer than 16 bytes.

Because you can configure four different functions for RADIUS with each function operating independently of the others and possibly interacting with different RADIUS servers (or clients), the MAX displays four separate VSA-related parameters for specifying whether to operate in the older Ascend mode or in VSA-compatible mode. Following are the relevant parameters, shown with their default settings:

####

####

     Parameter

     Description

     Ethernet > Mod Config > Auth > Auth Compat Mode

    Enables or disables VSA support when the MAX supports RADIUS for authentication. OLD is the default which disables VSA support.

     Ethernet > Mod Config > Accounting > Acct Compat Mode

    Enables or disables VSA support when the MAX supports RADIUS for accounting. OLD is the default which disables VSA support.

     Ethernet > Mod Config > RADIUS Server > Compat Mode

    Enables or disables VSA support when the MAX acts as a RADIUS server that is able to accept some requests for certain limited purposes; for example, to change filters or disconnect a user. OLD is the default which disables VSA support.

     Ethernet > Mod Config > Call Logging > Compat Mode

    Enables or disables VSA support when the MAX supports RADIUS for call logging to NavisAccess. OLD is the default which disables VSA support.

    For additional details, see the MAX Reference Guide.

## Using SNMP to specify the primary RADIUS server

By default, if the MAX uses a secondary RADIUS authentication server because the primary one goes out of service, the MAX does not use the first host until the second machine fails. This situation occurs even if the first host has come online while the second host is still servicing requests. However, you can use an SNMP set command to specify that the MAX use the first host again. Such a need might arise if you shut down the primary server for service and then make it available again.

Every time you reset the server using the set command, the MAX generates an SNMP trap. The MAX also generates a trap if it changes to the next server because the current server fails to respond. The trap is an Enterprise Specific Trap (18) and is accompanied by the Object ID and IP address for the new server. The Object ID for Authentication Server is 1.3.6.1.4.1.529.13.3.1.11.x. where x is the index of the current server (1-3).

For details, see the Ascend Enterprise MIB. You can download the most up-to-date version of the Ascend Enterprise MIB by logging in as `anonymous` to ftp.ascend.com. (No password is required.)

## Starting the RADIUS daemon

You can use two different RADIUS daemons:

- radiusd

  Run this daemon when you use a flat ASCII users file.

- radiusd.dbm

  Run this daemon when you convert the flat ASCII users file to a standard UNIX DBM database.

Because RADIUS must search the flat ASCII file sequentially, you might find that using this type of file slows down access time, especially if you have many users and many authentication requests. If you use the DBM database, RADIUS can locate a record by index with only a few database accesses.

The DBM database is no more difficult to use than the flat ASCII file, and is much faster. However, if you reset passwords, these passwords take effect only after you rebuild the database. If resetting expired passwords is an important component of your system, you may not wish to use the DBM database.

### Running the daemon with a flat ASCII users file

To start the RADIUS daemon with a flat ASCII users file, enter this command:

    radiusd [-A acct[-a acctdir]] [-c] [-d dbdir] [-p] [-s]

    [-u usrfile] [-v] [-w] [-x]

To enable call logging using RADIUS, start the RADIUS daemon with the `-A` option by entering this command line

    radiusd -A services | incr

If you specify the `services``` argument, the daemon creates the call-logging process, but only if a line defining the UDP port to use for call-logging appears in the`` `/etc/services` file. Otherwise, the daemon does not start.

If you specify the `incr` argument, the daemon creates the call-logging process with the UDP port specified as the call-logging port in the`` `/etc/services` file. If you have not defined the port, the daemon increments the UDP port specified for `radiusd` and uses that port number. This action is the default if you do not specify the `-A` argument.

Table 2-1 lists each argument.

Table 2-1. List of radiusd arguments

#### Argument

#### Description

-A acct

This argument controls the creation of the RADIUS accounting process. You can specify one of these values for acct:

none-The daemon does not create the accounting process.

services-The daemon creates the accounting process only if a line defining the UDP port to use for accounting appears in the
/etc/services file. Otherwise, daemon does not start.

incr-The daemon creates the accounting process with the UDP port specified as the accounting port in the /etc/services file. If you have not defined the port, the daemon increments the UDP port you specify for radiusd and uses that port number. This action is the default you do not specify the `-A` argument.

-a acctdir

By default, RADIUS stores accounting records in a file named detail that resides in the /usr/adm/radacct. You can use the -a argument to specify a different directory for the file. acctdir must already exist.

For example, you might enter this command line:

    radiusd -a /home/radacct

The accounting process in the daemon creates a file named detail that contains accounting records in the /home/radacct directory.

-c

This argument enables cache-token authentication in the daemon.

-d dbdir

The default directory for the RADIUS clients, users, dictionary, and log files is /etc/raddb. You can use the -d argument to specify a different directory for the files. dbdir`` must already exist. For example, you might enter this command line:

    radiusd -d /radius/raddb

-p

This argument enables each user to change his or her own expired password through a dial-in modem connection.

-s

This argument specifies that the daemon runs in single-process mode. In this mode, the daemon receives, processes, and returns one request before going to the next one. This mode is much slower than the default multiprocess mode, in which the daemon receives, processes, and returns several requests concurrently.

-u usrfile

This argument assigns the file name specified by usrfile`` to the RADIUS users file. The default name is users.

-v

This argument prints the daemon's version number, extension, date, and the arguments selected in the makefile compilation.

-w

This argument makes the RADIUS daemon generate warnings about syntax errors it finds in the users file when the daemon is running. RADIUS generates a warning only when the daemon examines the users file profiles during the authentication process. For a more complete scan of the file for syntax errors, use the builddbm command with the -e argument.

-x

This argument produces debug output.

### Running the daemon with a UNIX DBM database

To run the daemon with a UNIX DBM database, you must carry out three tasks:

1. Create two executable files: builddbm and radiusd.dbm.

- The builddbm file enables you to create the DBM database.

- The radiusd.dbm file is the version of the RADIUS daemon that you run when using the DBM database.

2. Create the database.

3. Start the RADIUS daemon.

#### Creating the executable files

To create the builddbm and radius.dbm executable files, enter this command:

    make dbm

#### Creating the DBM database

Before running radiusd.dbm, you must create the DBM database. To do so, enter this command line:

    builddbm [-d dbdir] [-e] [-h] [-u usrfile] [-v]

Note: You must run builddbm each time you modify the users file. If remote users are able to change their own expired passwords, you must run builddbm after each password change.

Table 2-2 lists each argument for the builddbm command.

Table 2-2. List of builddbm arguments

#### Argument | #### Description
--- | ---
-d dbdir | The default output directory for the database file is /etc/raddb. You can use the -d argument to specify a different directory for the file. dbdir`` must already exist. For example, you might enter this command line:
    builddbm -d /radius/raddb
This command results in two database files-/radius/raddb/users.dir and /radius/raddb/users.pag.
-e | This argument causes the builddbm program to report syntax errors and duplicate entries it finds in the users file during the indexing process. The daemon writes the messages to standard output. If you do not specify the -e argument, the daemon writes the entries to standard error output instead.
-h | This argument displays help.
-u usrfile | This argument specifies the RADIUS users file for which a database is being built. The default name is users. If the daemon runs with the -u argument, the name you specify when you run the daemon must be the same name you specify here. The users file must already exist in ASCII format. The resulting database files are named users.dir and users.pag.
-v | This argument runs builddbm in verbose mode.

#### Starting the RADIUS daemon for a DBM database

To start the RADIUS daemon in DBM mode, enter this command:

    radiusd.dbm

The radiusd.dbm command supports the same set of arguments described for the radiusd command in Running the daemon with a flat ASCII users file, with one exception: the -p argument is restricted when the daemon is running in DBM mode. The users file database will not contain the user's new password until you run builddbm again.

If you have enabled call-logging, start RADIUS daemon by entering this command line:

    radiusd.dbm -A services

You must specify the `services` argument when you start the daemon in DBM mode.

Copyright © 1998, Ascend Communications, Inc. All rights reserved.