[Top][Contents][Prev][Next][Last]Search

Installing and Starting RADIUS

This chapter, which describes how to install and start the RADIUS daemon, consists of the following sections:

Before you begin
Overview of RADIUS installation tasks
Installing the RADIUS daemon
Configuring the MAX TNT to use the RADIUS server
Configuring the MAX TNT for RADIUS client requests
Starting the RADIUS daemon

Before you begin

This section describes:

System requirements

 To use RADIUS with the MAX TNT, you need a UNIX workstation or PC to run the RADIUS daemon, and a TCP/IP connection between the RADIUS server and the MAX TNT. The supported platforms are:

Note: If you do not use the Ascend RADIUS daemon, the MAX TNT is limited to 256 session IDs. If all session IDs are used up, the MAX TNT cannot answer a call. If you are using the Ascend RADIUS daemon, the MAX TNT is not limited to 256 session IDs, and you need not concern yourself with using up available session IDs.

Configuring the MAX TNT

Before you install and configure RADIUS, you must carry out the following tasks at the MAX TNT configuration interface:

For details, see the MAX TNT Hardware Installation Guide and the MAX TNT Network Configuration Guide.

Overview of RADIUS installation tasks

No matter what kind of configuration exists at your site, you are required to carry out the following tasks:

Depending on your configuration, you may also need to configure the MAX TNT to accept client disconnect and filter-change requests. (For information, see Configuring the MAX TNT for RADIUS client requests.)

Installing the RADIUS daemon

To install the RADIUS daemon, you must perform the following tasks:

Obtaining and compiling the RADIUS daemon

 The installation instructions on the Ascend FTP server always provide the latest information about installing RADIUS. When you compile the daemon, be aware that 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.

To obtain and compile the RADIUS daemon:

  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.

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

Installing the Ascend RADIUS dictionary

The dictionary file is the Ascend RADIUS dictionary. It contains a list of all attributes that the RADIUS server supports.

You must install the dictionary in the same directory as the Ascend RADIUS daemon. By default, the RADIUS daemon resides in the /etc/raddb directory. The dictionary 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 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 restart it to make the new attributes available. For further information about the dictionary file, see The dictionary file.

Creating and configuring the clients file

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 TNT is an NAS and a client of the RADIUS server. For the RADIUS daemon to respond to requests from the MAX TNT, you must create a file called clients in the /etc/raddb directory, and then specify the MAX TNT unit's name and password in the file.

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

Ascend3      bXSAMpy
Ascend3 is the value specified by the Name parameter. The argument bXSAMpy is the password specified by the Auth-Key parameter. 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 TNT.

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 Rad-Acct-Client subprofile of the External-Auth profile.

Creating the users file

Create a file called users in the /etc/raddb directory. A user is a caller that connects to the MAX TNT. 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 TNT 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 TNT unit's memory. RADIUS authentication occurs when the caller's name and password match a user profile in the RADIUS users file.

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

Creating the log file

Create a file called 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.

Specifying the MAX TNT unit's name and IP address

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

Specifying the RADIUS daemon's authentication port

Use a text editor to open the /etc/services file and add a line identifying the port on which the RADIUS daemon receives authentication requests.

For example:

RADIUS      1812/udp
The port number you specify must match the port number indicated by the Auth-Port parameter in the Rad-Auth-Client subprofile of the External-Auth profile.

Configuring the MAX TNT to use the RADIUS server

This section describes how to configure the MAX TNT to communicate with the RADIUS daemon. You use the MAX TNT configuration interface to carry out each step. Some steps are required for all configurations. Others are optional, and depend on the needs of your site. For complete information about each parameter you set, see the MAX TNT Reference Guide.

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

Performing the required configuration steps

When configuring the MAX TNT to use RADIUS, you must specify:

You can have up to three RADIUS servers on your network. One is the primary server. Two additional servers can function as backups. If the primary RADIUS server fails, the MAX TNT automatically contacts the secondary RADIUS server to authenticate a user. When it successfully connects to an authentication server, the MAX TNT uses that machine until it fails to serve requests. By default, the MAX TNT does not revert to using 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 TNT use the first host again. For details, see Using SNMP to specify the primary RADIUS server.

To specify settings required for RADIUS operation:

  1. In the External-Auth profile, set the Auth-Type parameter to RADIUS.

  2. Open the Rad-Auth-Client subprofile.

  3. For each Auth-Server parameter, specify the IP address of a RADIUS server.

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

    If you specify the same address for all three Auth-Server parameters, the MAX TNT keeps trying to create a connection to the same server.

  4. Set the Auth-Port parameter to the destination UDP port number on which the RADIUS daemon receives client requests. Specify the same number you set for the daemon in
    the /etc/services file.

  5. Set the Auth-Key parameter to the RADIUS client password you specified in the RADIUS clients file. (The password is case sensitive.)

Performing the optional configuration steps

 Depending on your needs, you can set parameters to:

The following sections describe the kinds of settings you can make.

Configuring distinct ID sequences for packet IDs

RADIUS uses an ID value to aid in Request-Response matching. By default, the MAX TNT uses a single sequence space for the RADIUS ID number in all RADIUS messages, which limits the number of IDs available for assignment to 256. A combined total of 256 authentication and accounting packets are sent before the ID sequence rolls over. However, by setting Rad-ID-Space=Distinct in the External-Auth profile, you can configure distinct ID sequence spaces for RADIUS accounting and authentication packets.

When you set Rad-ID-Space=Distinct, RADIUS authentication and accounting packets do not share the same ID sequence space. The MAX TNT can send a total of 256 authentication packets before the authentication ID sequence rolls over, and 256 accounting packets before the accounting ID sequence rolls over. Three sequence spaces are allocated: one for the Unified sequence space, one for the authentication ID sequence, and one for the accounting ID sequence.

When you configure the MAX TNT to use distinct ID sequence spaces, the RADIUS server must perform additional checks for duplicate detection. The server should check the RADIUS ID value as well as the service type and destination UDP port in each packet. The service type can be determined by sorting all values of the code field into two classes-Auth and Acct-and then comparing the received code value to determine to which class it belongs. The destination UDP port can be the same for both services when a single RADIUS server performs them.

Fine-tuning the interaction between the MAX TNT and RADIUS

All the steps that follow set parameters in the External-Auth profile's Rad-Auth-Client subprofile. To fine-tune the interaction between the MAX TNT and RADIUS, proceed as follows:

  1. Set the Auth-Pool parameter to specify whether the MAX TNT sends the IP address derived from pool #1 to the RADIUS server during an authentication request. (For information about the Auth-Pool parameter, see Setting up accounting with dynamic IP addressing.)

  2. Set Auth-Rsp-Required=Yes to enforce Calling-Line ID (CLID) authentication for connections that require it. (For detailed information about CLID authentication, see Setting up CLID authentication.)

  3. Set the Local-Profiles-First parameter to specify whether the MAX TNT first checks for a local Connection profile when attempting to authenticate a connection.

  4. Set the Auth-Sess-Interval parameter to specify the interval in seconds at which the MAX TNT sends session reports.

  5. Set the Auth-Src-Port parameter to a value representing the MAX TNT unit's UDP source port for sending RADIUS authentication requests. (You can specify the same value for authentication and accounting requests.)

  6. If your RADIUS user profiles enable both framed and unframed users to access PPP, set Auth-Send67=No. A framed user dials in using a protocol such as SLIP or MP+. An unframed user makes an asynchronous connection to the terminal server, and can start Telnet, Rlogin, or raw TCP sessions.

Specifying the duration of a RADIUS timeout

 In the Rad-Auth-Client subprofile of the External-Auth profile, set the Auth-Timeout parameter to the number of seconds the MAX TNT waits for a response to a RADIUS authentication request. If you have a high volume of calls, consider a low value for Auth-Timeout. A high timeout value combined with a high call volume can significantly slow the process of authenticating calls. However, if RADIUS is running on a busy shared UNIX host, or if the RADIUS server is on the remote end of a slow link, consider increasing the timeout value above the default of 1 second.

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

Note: If you are not using the Ascend RADIUS daemon, the MAX TNT is limited to 256 session IDs. In this case, you must make sure that the timeout period is short enough that all session IDs are not used up while the MAX TNT is waiting for an authentication response. If you are using the Ascend RADIUS daemon, the MAX TNT is not limited to 256 session IDs. In this case, a lower timeout value will help you eliminate delays in call authentication, but you need not concern yourself with a limitation on session IDs.

Specifying the message resulting from a RADIUS timeout

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. If Windows '95 (MSN) receives the LCP-CLOSE during authentication, it displays an invalid-password message. This message is misleading if the failure resulted from a RADIUS timeout.

When you set Disconnect-On-Auth-Timeout=Yes in the Answer-Defaults profile's PPP-Answer subprofile, the resulting message to the user states that the network failed.

Example of configuring the MAX TNT to use the RADIUS server
The configuration illustrated in Figure 2-1 uses three RADIUS servers. Clients dialing in across the WAN use both framed and unframed protocols on analog and digital lines. The RADIUS daemon for each server receives client requests on UDP port 512, and the client password is tntpass.

Figure 2-1. Sample network topology for setting up the MAX TNT to use the RADIUS server

In addition to the required parameters, the configuration also specifies that the MAX TNT must:

To set the values for the sample configuration, you would proceed as follows:

admin> read external-auth

EXTERNAL-AUTH read

admin> list

auth-type=none

acct-type=none

rad-id-space=unified

rad-id-source-unique=system-unique

rad-serv-enable=no

rad-auth-client={ 0.0.0.0 0.0.0.0 0.0.0.0 0 0 "" no 0 no no no 0 yes +

rad-acct-client={ 0.0.0.0 0.0.0.0 0.0.0.0 0 0 "" 0 0 acct-base-10 0 +

rad-auth-server={ 0 no rad-serv-attr-any [ 0.0.0.0 0.0.0.0 0.0.0.0 +

tac-auth-client={ 0.0.0.0 0.0.0.0 0.0.0.0 0 0 "" 0 }

tacplus-auth-client={ 0.0.0.0 0.0.0.0 0.0.0.0 0 0 "" 0 0 }

tacplus-acct-client={ 0.0.0.0 0.0.0.0 0.0.0.0 0 0 "" }

local-profiles-first=lpf-yes

admin> set auth-type=radius

admin> set rad-id-space=distinct

admin> list rad-auth-client

auth-server-1=0.0.0.0

auth-server-2=0.0.0.0

auth-server-3=0.0.0.0

auth-port=0

auth-src-port=0

auth-key=""

auth-pool=no

auth-timeout=0

auth-rsp-required=no

auth-id-fail-return-busy=no

auth-id-timeout-return-busy=no

auth-sess-interval=0

auth-TS-secure=yes

auth-Send67=yes

auth-frm-adr-start=no

auth-reset-time=0

admin> set auth-server-1=10.1.2.1

admin> set auth-server-2=10.1.2.2

admin> set auth-server-3=10.1.2.3

admin> set auth-port=512

admin> set auth-key=tntpass

admin> set auth-rsp-required=yes

admin> set local-profiles-first=lpf-no

admin> set auth-sess-interval=60

admin> set auth-src-port=500

admin> set auth-send67=no

admin> set auth-timeout=10

admin> write external-auth

EXTERNAL-AUTH written

Using SNMP to specify the primary RADIUS server

 By default, if the MAX TNT switches to a secondary RADIUS authentication server because the primary server goes out of service, the MAX TNT does not use the first host again until the second machine fails. However, you can use an SNMP Set command to specify that the MAX TNT use the first host again. Such a need might arise if the primary server is shut down for service and then becomes available again.

Every time you reset the server with the Set command, the MAX TNT generates an SNMP trap. The MAX TNT 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).

The following MIB objects support changing the current RADIUS authentication server:

radAuthHostIPAddress OBJECT-TYPE

	SYNTAX		 IpAddress

	ACESS		 read-only

	STATUS		 mandatory

	DESCRIPTION	 "The IP address of the Authentication server.

	The value 0.0.0.0 is returned if entry is invalid."

	::= { radiusAuthStatsEntry 11 }

radAuthCurrentServerFlag OBJECT-TYPE

	SYNTAX		      INTEGER {

			          standby(1),

			          current(2)

			      }

	ACCESS		      read-write

	STATUS		      mandatory

	DESCRIPTION  "Value indicates whether this entry is the

	current authentication server or not. Writing any value

	will cause the current server to be reset to the primary

	server (Host #1)."

	::= { radiusAuthStatsEntry 12 }

Configuring the MAX TNT for RADIUS client requests

As an option, you can configure the MAX TNT to accept RADIUS requests from clients to disconnect a link or change filters for a particular session, user, or IP address. To do so, you need to write your own RADIUS client software that performs disconnects or changes filters. Then, you need to set up the MAX TNT and set several RADIUS attributes.

This section describes how to set up the MAX TNT to handle RADIUS client requests. (For detailed information about specifying disconnects in RADIUS, see Setting up disconnects. For detailed information about specifying filter changes in RADIUS, see Setting up filter changes.)

The process of configuring the MAX TNT for client requests involves both required and optional steps. You perform all the steps by setting parameters in the Rad-Auth-Server subprofile of the External-Auth profile.

Performing the required steps for client requests

You must specify the clients permitted to make requests, and the secret shared between each client and the RADIUS server.

Specifying the clients permitted to make RADIUS requests

To specify the clients permitted to make RADIUS requests, you must use one of the following settings:

Specify each IP address or range in dotted decimal notation. The default value is 0.0.0.0. A value of 0.0.0.0 disables the associated parameter. At least one of the parameters must contain an IP address other than 0.0.0.0 for client support to be active.

For example, you can specify values like the following:

Specifying the shared secret

 Set the Auth-Key parameter to specify the secret shared by each client and the RADIUS server. You can specify a different secret for each client, or specify the same one. RADIUS uses the key to validate the authenticator field in requests and to generate the authenticator for responses. You can enter up to 20 characters.

Performing the optional steps for client requests

When setting up the MAX TNT to accept client requests, you can perform the following optional tasks:

Specifying the UDP port

 To indicate the number of the destination UDP port on which the RADIUS server receives client requests, set the Auth-Port parameter. You can enter an integer from 1 to 65535. The default value is 1700. Although the value can match the port setting for RADIUS authentication or accounting, Ascend recommends that you specify a different port.

Specifying session key parameters

If you want the client to send a session key to the RADIUS server, set the Auth-Session-Key parameter to Yes. The session key associates the client request with the user session. When you specify Yes, the client sends a session key specified by the Ascend-Session-Svr-Key attribute. When you specify No, the client does not send a session key. The default value is No.

If you set Auth-Session-Key=Yes, you must set the Auth-Attribute-Type parameter to specify the attributes required for identification of a user session. You can specify one of the following values:

For example, if a session has a user name, IP address, session ID, and session key specified, a client must send all four attributes to the RADIUS server, and all these attributes must pass validation. However, if a session has only an associated user name, session ID and session key, the client needs to send only those attributes. The IP address is not required.

Example of setting up the MAX TNT to accept client requests
In configuration illustrated in Figure 2-2, the following clients are authorized to make RADIUS requests:

Figure 2-2. Sample network topology for setting up the MAX TNT to accept client requests

The shared secret is secret001 for client #1, secret002 for client #2, and secret003 for client #3. Each client must send the session key specified by the Ascend-Session-Svr-Key attribute. To set the values for the sample configuration, you would proceed as follows:

admin> read external-auth

EXTERNAL-AUTH read

admin> list

auth-type=none

acct-type=none

rad-id-space=unified

rad-id-source-unique=system-unique

rad-serv-enable=no

rad-auth-client={ 0.0.0.0 0.0.0.0 0.0.0.0 0 0 "" no 0 no no no 0 yes +

rad-acct-client={ 0.0.0.0 0.0.0.0 0.0.0.0 0 0 "" 0 0 acct-base-10 0 0+

rad-auth-server={ 0 no rad-serv-attr-any [ 0.0.0.0 0.0.0.0 0.0.0.0 +

tac-auth-client={ 0.0.0.0 0.0.0.0 0.0.0.0 0 0 "" 0 }

tacplus-auth-client={ 0.0.0.0 0.0.0.0 0.0.0.0 0 0 "" 0 0 }

tacplus-acct-client={ 0.0.0.0 0.0.0.0 0.0.0.0 0 0 "" }

local-profiles-first=lpf-yes

admin> list rad-auth-server

auth-port=1700

auth-session-key=no

auth-attribute-type=rad-serv-attr-any

auth-client=[ 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0+

auth-netmask=[ 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 +

auth-key=[ "" "" "" "" "" "" "" "" "" ]     

admin> list auth-client

auth-client[1]=0.0.0.0

auth-client[2]=0.0.0.0

auth-client[3]=0.0.0.0

auth-client[4]=0.0.0.0

auth-client[5]=0.0.0.0

auth-client[6]=0.0.0.0

auth-client[7]=0.0.0.0

auth-client[8]=0.0.0.0

auth-client[9]=0.0.0.0

admin> set 1=135.50.248.76

admin> set 2=145.55.248.76

admin> set 3=125.60.5.1

admin> list ..

auth-port=1700

auth-session-key=no

auth-attribute-type=rad-serv-attr-any

auth-client=[ 135.50.248.76 145.55.248.76 125.60.5.1 0.0.0.0 0.0.0.0 +

auth-netmask=[ 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 +

auth-key=[ "" "" "" "" "" "" "" "" "" ]     

admin> list auth-key

auth-key[1]=""

auth-key[2]=""

auth-key[3]=""

auth-key[4]=""

auth-key[5]=""

auth-key[6]=""

auth-key[7]=""

auth-key[8]=""

auth-key[9]=""

admin> set 1=secret001

admin> set 2=secret002

admin> set 3=secret003

admin> list ..

auth-port=1700

auth-session-key=no

auth-attribute-type=rad-serv-attr-any

auth-client=[ 135.50.248.76 145.55.248.76 125.60.5.1 0.0.0.0 0.0.0.0 +

auth-netmask=[ 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 +

auth-key=[ ********** ********* ********* "" "" "" "" "" "" ]     

admin> set auth-session-key=yes

admin> set auth-attribute-type=rad-serv-attr-key

admin> write

EXTERNAL-AUTH written

Starting the RADIUS daemon

You can use one of two RADIUS daemons-radiusd or radiusd.dbm.

RADIUS must search a flat ASCII file sequentially, which might increase 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, the new passwords take effect only after you rebuild the database. If resetting expired passwords is an important component of your system, the flat ASCII file might be the better choice.

Running the daemon with a flat ASCII users file

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

radiusd [-A acct [-a acctdir]] [-c] [-d dbdir] [-p] [-s] [-u usrfile] 
[-v] [-w] [-x]
Table 2-1 lists each argument.

Table 2-1. List of radiusd arguments

Argument

Description
-A acct

 Controls the creation of the RADIUS accounting process. You can specify one of the following 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 specified for radiusd and uses that port number. This action is the default if you do not specify the -A argument.

-a acctdir

 Specifies the directory containing accounting records.

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

For example, you might enter the following command line:

radiusd -a /home/radacct

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

-c

 Enables Cache-Token authentication in the daemon.

-d dbdir

 Specifies the directory containing the clients, users, dictionary, and log files.

The default directory is /etc/raddb. You can use the -d argument to specify a different directory for the files. The dbdir directory must already exist. For example, you might enter the following command line:

radiusd -d /radius/raddb

-p

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

-s

 Specifies that the daemon runs in single-process mode, in which it 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

 Assigns the file name specified by usrfile to the RADIUS users file. The default name is users.

-v

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

-w

 Makes the RADIUS daemon generate warnings about syntax errors found in the users file when the daemon is running. RADIUS generates a warning only when the daemon examines the user 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

 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.

  2. Create the database.

  3. Start the RADIUS daemon.

Creating the executable files

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

make dbm

Creating the DBM database

 Before running radiusd.dbm, you must create the DBM database. To do so, enter the following 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 list each argument for the builddbm command.

Table 2-2. List of builddbm arguments

Argument

Description
-d dbdir

 Specifies the directory containing the database files.

The default output directory for the database files is /etc/raddb. You can use the -d argument to specify a different directory for the file. The dbdir directory must already exist. For example, you might enter the following command line:

builddbm -d /radius/raddb

This command results in two database files-/radius/raddb/users.dir and /radius/raddb/users.pag.

-e

 Causes the builddbm program to report syntax errors and duplicate entries found 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

 Displays help.

-u usrfile

 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 specified 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

 Runs builddbm in verbose mode.

Starting the RADIUS daemon for a DBM database

To start the RADIUS daemon in DBM mode, enter the following 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.


[Top][Contents][Prev][Next][Last]Search

techpubs@eng.ascend.com

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