Radiator Radius Server

6.3.1 Foreground

If this parameter is set, it makes the server run in the foreground instead of as a detached daemon. No argument is required. The default behaviour is to run as a daemon. You must run in the foreground if you want to run Radiator from inetd (see Section 16.3 ), or from restartWrapper (see Section 16.1 ).

 
# Run in the foreground
Foreground

6.3.2 LogStdout

If this parameter appears, it makes all logging output appear on STDOUT as well as in the log file. No argument is required. The default behaviour is not to log to STDOUT. You must be running in Foreground mode for this to have an effect.

 
# Log to stdout
LogStdout

6.3.3 Trace

Sets the priority level of trace messages to be logged in the log file (and printed on stdout if LogStdout is defined). The argument is an integer from 0 to 5, with the following meanings:

• 0 ERR. Error conditions. Serious and unexpected failures
• 1 WARNING. Warning conditions. Unexpected failures
• 2 NOTICE. Normal but significant conditions.
• 3 INFO. Informational messages.
• 4 DEBUG. Debugging messages.
• 5 Incoming raw packet dumps in hexadecimal.

A trace level of 4 or more will produce all the possible tracing messages, including dumps of every Radius message received and sent: you probably don't want that in a production environment. The default tracing level is 0. You can change the current tracing level while Radiator is running on Unix platforms by signalling it with SIGUSR1 and SIGUSR2. See Section 7.0 .

 
# Show everything up to and including INFO level
Trace	 3

6.3.4 AuthPort

Specifies which port Radiator will listen on for Radius authentication requests. The argument may be either a numeric port number or an alphanumeric service name as specified in /etc/services (or its moral equivalent on your system). The default port is 1645. Note that the officially assigned port number for Radius accounting has recently been changed to 1812.

 
# Listen for authentication requests on port 1812 as per RFC 
# 2138
AuthPort 1812

Note: Actually Radiator will also service accounting requests received on the authentication port without complaint.

6.3.5 AcctPort

Specifies which port Radiator will listen on for Radius accounting requests. The argument may be either a numeric port number or an alphanumeric service name as specified in / etc/services (or its moral equivalent on your system). The default port is 1646. Note that the officially assigned port number for Radius accounting has recently been changed to 1813.

 
# Listen for accounting requests on port 1813 as 
# per RFC 2139
AcctPort 1813

Note: Actually Radiator will also service authentication requests received on the accounting port without complaint.

6.3.6 BindAddress

This optional parameter specifies a single host address to listen for Radius requests on. It is only useful if you are running Radiator on a multi-homed host (i.e. a host that has more than one network address). Defaults to 0.0.0.0 (i.e. listens on all networks connected to the host).

 
# Only listen on one network
BindAddress 203.63.154.0

6.3.7 LogDir

Specifies the directory to be used to store log files. Defaults to / var/log/radius . For convenience, the LogDir directory name can be referred to as %L in any file name path in this configuration file.

 
# Put log files in /opt/radius instead
LogDir /opt/radius

6.3.8 DbDir

Specifies the directory to be used for user database files. Defaults to /usr/local/etc/raddb . For convenience, the DbDir directory name can be referred to as %D in any file name path in this configuration file.

 
# Look in /opt/etc/raddb for username database
DbDir /opt/etc/raddb

6.3.9 LogFile

The name of the log file. All logging messages will be time stamped and written to this file. Each time this file is written to by Radiator, it opens, writes and then closes the file. This means that you can safely rotate the log file at any time. The file name can include special path name characters as defined in Special characters in file names and other parameters . The default is %L/logfile , i.e. a file named logfile in LogDir.

You can disable all logging to the log file by setting LogFile to be the empty string.

 
# Log file goes in /var/log, with year number
LogFile /var/log/%Y-radius.log
# Disable logging to log file completely
LogFile

Technical note: If LogFile is defined in your configuration file, a <Log FILE> will be invisibly created to handle it. See Section 6.7 .

6.3.10 DictionaryFile

The name of the Radius dictionary file. The dictionary file defines the names to be used for Radius attributes and their values. Its format is described in Section 15.1 . The file name can include special path name characters as defined in "Special characters in file names" on page 4. The default is %D/dictionary , i.e. a file called "dictionary" in DbDir. A dictionary file called "dictionary" that will work with most terminal servers is included in the Radius distribution.

 
# Dictionary file is in the current directory
DictionaryFile ./dictionary

6.3.11 PidFile

The name of the file where radiusd will write its process ID (PID) at start-up. Defaults to %L/radiusd.pid. The file name can include special path name characters as defined in Special characters in file names and other parameters .

 
# So we don't conflict with another radiusd
PidFile /tmp/radiusd2.pid

6.3.12 Syslog

This parameter is now obsolete, and is replaced by the <Log SYSLOG> clause. See Section 6.8 .

6.3.13 SnmpgetProg

Specifies the full path name to the snmpget program. This optional parameter is only used if you are using Simultaneous-Use with a NasType of Livingston or any other NAS type that uses SNMP (see Figure 2 ) in one of your Client clauses. Defaults to /usr/bin/snmpget .

 
SnmpgetProg /usr/local/bin/snmpget

6.3.14 FingerProg

Specifies the full path name to an external finger program. This optional parameter is only used if you are using Simultaneous-Use with a NasType of Portslave, Ascend, Shiva, Computone or any other NAS type that uses finger (see Figure 2 ) in any of your Client clauses. Defaults to using an internal finger client that does not require an external program.

 
FingerProg /usr/local/bin/finger

6.3.15 PmwhoProg

Specifies the full path name to the pmwho program. This optional parameter is only used if you are using Simultaneous-Use with a NasType of TotalControl or any other NAS type that uses pmwho (see Figure 2 ) in one of your Client clauses. Defaults to /usr/local/sbin/pmwho .

 
PmwhoProg /usr/local/bin/pmwho

6.3.16 LivingstonMIB

This optional parameter specifies the name of the Livingston SNMP MIB. It is only used if you are using Simultaneous-Use with a NasType of Livingston in one of your Client clauses. Defaults to .iso.org.dod.internet.private.enterprises.307

6.3.17 LivingstonOffs

Specifies the global default value of where the last S port is before the one or two ports specified in LivingstonHole are skipped (usually 22 for US, 29 for Europe). This optional parameter is only used if you are using Simultaneous-Use with a NasType of Livingston in one of your Client clauses. Defaults to 29.This value can be overridden on a per-Client basis by using LivingstonHole in a Client clause, see Section 6.4.11 .

6.3.18 LivingstonHole

Specifies the global default value of the size of the hole in the port list (usually 1 for US, 2 for Europe) that occurs at LivingstonOffs. This optional parameter is only used if you are using Simultaneous-Use with a NasType of Livingston in one of your Client clauses. Defaults to 2. This value can be overridden on a per-Client basis by using LivingstonHole in a Client clause, see Section 6.4.12 .

6.3.19 RewriteUsername

This parameter enables you to alter the User-Name in authentication and accounting requests. For more details, see Section 14.0 . You can also rewrite user names on a per-Client or per-Realm basis (see Section 6.3.19 and Section 6.4.8 ).

You can have any number of RewriteUsername parameters. The rewrites will be applied to the user name in the same order that they appear in the configuration file. The rewrites are applied before any per-Client or per-Realm rewrites. At Trace level 4, you can see the result of each separate rewrite for debugging purposes.

 
# Convert all user@realm1 to user@realm2, then
# change any user named mikem into fred
RewriteUsername	     s/^([^@]+)@realm1/$1@realm2/
RewriteUsername     s/^mikem@/fred@/

# Convert a MSN realm/user into user@realm
RewriteUsername    s/^(.*)\/(.*)/$2\@$1/

# Translate all uppercase to lowercase
RewriteUsername   tr/A-Z/a-z/

6.3.20 SocketQueueLength

This optional parameter allows you to alter the lengths of the radius socket queues from their default Operating-System specific value. You may wish to set the queue lengths to be longer than the default if your Radiator server is handling very large numbers of requests, and is near its performance limits. You should never need to set them to shorter than the default. SocketQueueLength affects the length of both the authentication and the accounting socket queues. SocketQueueLength has no effect on Win95 or NT.

Hint: You may need special privileges, or you may need to change your Operating System configuration to permit longer queue lengths than the default. Consult your operating system manuals for details on how to do this.

 
# Make a long queue length
SocketQueueLength 1000000

6.3.21 PreClientHook

This optional parameter allows you to define a Perl function that will be called during packet processing. PreClientHook is called for each request before it is passed to a Client clause. It will be called even if there is no Client defined for the request. A reference to the current request is passed as the only argument.

The hook code is compiled by Perl when Radiator starts up. Compilation errors in your hook code will be reported to the log file at start-up time. Runtime errors in your hook will also be reported to the log file when your hook executes. Multiline hooks (i.e. with trailing backslashes (\)) are parsed by Radiator into one long line. Therefore you should not use trailing comments in your hook.

PreClientHook can be an arbitrarily complicated Perl function, that might run external processes, consult databases, change the contents of the current request or many other things.

 
# Fake a new attribute into the request
PreClientHook sub { ${$_[0]}->add_attr(`test-attr', \
                      `test-value');}

6.4.1 Secret

This defines the shared secret that will be used to decrypt Radius messages that are received from this client. You must define a shared secret for each Client, and it must match the secret configured into the client Radius software. There is no default. The secret can be any number of ASCII characters. Any ASCII character except newline is permitted, but it might be easier if you restrict yourself to the printable characters. For a reasonable level of security, the Secret should be at least 16 characters, and a mixture of upper and lower case, digits and punctuation. You should not use just a single recognizable word.

 
# This better agree with the client at
# oscar.open.com.au or we wont understand them!
<Client oscar.open.com.au>
	    Secret 666obaFGkmRNs666
</Client>

6.4.2 DefaultRealm

This optional parameter can be used to specify a default realm to use for requests that don't already have a realm. The realm can then be used to trigger a specific <Realm> clause. This is useful if you operate a number of NASs for different customer groups and where all your customers log in without specifying a realm.

 
# Realmless logins to this NAS will be treated
# as if they are for realm open.com.au
<Client acc1.open.com.au>
   Secret ....
   DefaultRealm open.com.au
</Client>
<Realm open.com.au>
   .....
</Realm>

6.4.3 IgnoreAcctSignature

If defined, this parameter causes prevents the server from checking the "authenticator" (sometimes called the signature) in accounting requests received from this client. This is useful because some clients (notably early Merit Radius servers and the GRIC server when forwarding) do not send Authenticators that conform to RFC 2139, while some other NASs do not set the authenticator at all. By default, the server will check the Authenticator in accounting requests. By default, it will log and ignore (i.e. not respond to) accounting requests that do not have a correct Authenticator. Regardless of the setting of this parameter, the server will always send a correctly computed Authenticator in reply to accounting requests. If you keep seeing log messages like:

 
Bad authenticator in request from <client name
>

and your accounting requests are not being stored, but you are authenticating OK, and you are sure the shared secrets are correct, you might try enabling this parameter.

 
# brian.open.com.au has a broken NAS
<Client brian.open.com.au>
	    Secret 666obaFGkmRNs666
    IgnoreAcctSignature
</Client>

6.4.4 DupInterval

If more than 1 Radius request from this Client with the same Radius Identifier are received within DupInterval seconds, the 2nd and subsequent are ignored. A value of 0 means duplicates are always accepted, which might not be very wise, except during testing. Default is 2 seconds, whcih will detect and ignore duplicates due to multiple transmission paths. In general you should never need to worry about or set this parameter. Ignore it and accept the default.

 
# brian.open.com.au is being tested
<Client brian.open.com.au>
	    Secret 666obaFGkmRNs666
    DupInterval 0
</Client>

6.4.5 NasType

This optional parameter specifies the vendor type of this Client. It is required if you want Radiator to directly query the NAS to check on simultaneous sessions. The allowable values for NasType are:

You can specify the maximum number of sessions allowable for a single user with the Simultaneous-Use check item, or for all the users in a Realm with the MaxSessions parameter in <Realm> or <Handler> clauses. In either case, during authentication, Radiator first checks its Session Database (see Section 6.5 and Section 6.6 ) to see if the user's session count is exceed. Since this count can be inaccurate in the face of NAS reboots etc., Radiator can also double check the count by interrogating the NAS directly (you enable this by specifying NasType in the Client clause, see Section 6.4.5 ).

If you specify "unknown" or do not specify any value at all, Radiator will never try to contact the NAS to check the user's sessions, and it will always assume that the sessions it thinks are present are correct. If you specify "ignore", Radiator will never try to contact the NAS to check the users sessions, and it will always assume that there are no multiple sessions.

Hint : If Radiator detects problems or timeouts when using finger to verify simultaneous connections, it assumes that the user is still online (i.e. it assumes that the SessionDatabase is correct).

Radiator uses a number of global parameters to specify how to communicate with the NAS. See SnmpgetProg, FingerProg PmwhoProg, LivingstonMIB , LivingstonOffs and LivingstonHole .

 
# Make Radiator ask the NAS to confirm multiple logins.
# its a Total Control box
NasType TotalControl

6.4.6 SNMPCommunity

This optional parameter specifies the SNMP Community name to use to connect to the NAS when NasType uses SNMP. It is ignored for any other NasType. Defaults to `public'.

 
SNMPCommunity   private

6.4.7 FramedGroupBaseAddress

This optional parameter is used in conjunction with the Framed-Group reply attribute or the FramedGroup AuthBy parameter to automatically generate IP addresses for users logging in. It is ignored unless the user has a Framed-Group reply item, or unless their AuthBy clause contains a FramedGroup parameter. You can have as many FramedGroupBaseAddress items as you like.

You would only need to use this mechanism if you are using a NAS that is unable to choose IP addresses from an address pool, or if you want a more complicated address allocation policy than your NAS can support.

When a user logs in, Radiator can automatically choose an IP address for the user and return it to the NAS in a Framed-IP-Address reply attribute. To make this happen, you must specify one or more FramedGroupBaseAddress items in each Client clause, and you must specify a Framed-Group reply item for each user for whom you want address allocation. If the user is authenticated, Radiator will generate a Framed-IP-Address using Framed-Group reply item and the NAS-Port in the request. The Framed-Group in a user record selects the nth FramedGroupBaseAddress (0 based) from the Client they are logging in to, and NAS-Port is added to the last byte (modulo 255) to generate a Framed-IP-Address.

In the example below, if the user logs in on the Client at port 5, and their Framed-Group reply item is 1, they will be allocated a Framed-IP-Address of 10.0.1.6 (i.e. 10.0.1.1 + 5)

In the Radiator configuration file:

 
<Client ..>
    # This is the base address for Framed-Group = 0
    FramedGroupBaseAddress    10.0.0.1
    # This is the base address for Framed-Group = 1
    	FramedGroupBaseAddress    10.0.1.1
    # This is the base address for Framed-Group = 2
    	FramedGroupBaseAddress    10.0.2.1
    ....
</Client>

In the users file for each user you want to allocate an address for:

 
mikem    User-Password = "fred"
         Framed-Group = 1,
         Framed-Protocol = PPP,
             etc.

Alternatively, in an AuthBy clause:

 
<AuthBy whatever...>
	# This will cause all users authorized by this clause to get
	# an address allocated from the block starting 10.0.1.1,
	# unless overridden by a user-specific Framed-Group
	FramedGroup 1
	.....
</AuthBy>

6.4.8 RewriteUsername

This parameter enables you to alter the user name in all authentication and accounting requests from this client. For more details, see Section 14.0 .

You can have any number of RewriteUsername parameters. The rewrites will be applied to the user name in the same order that they appear in the configuration file. The rewrites are applied after any global rewrites, but before any per-Realm rewrites. At Trace level 4, you can see the result of each separate rewrite for debugging purposes.

 

# Convert all user@realm1 to user@realm2, then
# change any user named mikem into fred
RewriteUsername	     s/^([^@]+)@realm1/$1@user.realm2/
RewriteUsername     s/^mikem@/fred@/

# Convert a MSN realm/user into user@realm
RewriteUsername    s/^(.*)\/(.*)/$2\@$1/

# Translate all uppercase to lowercase
RewriteUsername   tr/A-Z/a-z/

6.4.9 IdenticalClients

This optional parameter specifies a list of other clients that have an identical setup. You can use this parameter to avoid having to create a separate Client clauses for lots of otherwise identical clients. The value is a list of client names or addresses, separated by white space. You can have any number of IdenticalClients lines.

 
IdenticalClients 10.1.1.1 10.1.1.2 nas.mydomain.com
	IdenticalClients 10.1.1.7 10.1.1.8 10.1.1.9
IdenticalClients 203.63.154.1 localhost

6.4.10 PreHandlerHook

This optional parameter allows you to define a Perl function that will be called during packet processing. PreHandlerHook is called for each request after per-Client username rewriting and duplicate rejection, and before it is passed to a Realm or Handler clause. A reference to the current request is passed as the only argument.

The hook code is compiled by Perl when Radiator starts up. Compilation errors in your hook code will be reported to the log file at start-up time. Runtime errors in your hook will also be reported to the log file when your hook executes. Multiline hooks (i.e. with trailing backslashes (\)) are parsed by Radiator into one long line. Therefore you should not use trailing comments in your hook.

PreHandlerHook can be an arbitrarily complicated Perl function, that might run external processes, consult databases, change the contents of the current request or many other things.

 
# Fake a new attribute into the request
PreHandlerHook sub { ${$_[0]}->add_attr(`test-attr', \
                     `test-value');}

6.4.11 LivingstonOffs

Specifies the value of where the last S port is before the one or two ports specified in LivingstonHole are skipped (usually 22 for US, 29 for Europe). This optional parameter is only used if you are using Simultaneous-Use with a NasType of Livingston in this Client clause. Defaults to the global value of LivingstonOffs, see Section 6.3.17 .

6.4.12 LivingstonHole

Specifies the value of the size of the hole in the port list (usually 1 for US, 2 for Europe) that occurs at LivingstonOffs. This optional parameter is only used if you are using Simultaneous-Use with a NasType of Livingston in this Client clause. Defaults to the global value of LivingstonOffs, see Section 6.3.18 .

6.5.1 Identifier

This optional parameter assigns a name to the Session Database, so it can be referred to in other parts of the configuration file, such as the SessionDatabase parameter in Handler.

 
# Here is a useful name for this Session Database
Identifier SDB1

6.5.2 DBSource

This parameter is used by Perl DBI to specify the database driver and database system to connect to. It will usually begin with dbi:driver_name: . There is no standard for the text following the driver name. You will have to consult the documentation for your DBD driver. Some examples are given below

 
# Connect to mSQL database called radius on localhost, 
# standard port
DBSource dbi:mSQL:radius
# Or... Connect to the Oracle sid called users
DBSource dbi:Oracle:users
# Or... Connect to mysql database called radius on localhost,
# standard port
DBSource dbi:mysql:radius

6.5.3 DBUsername

For most database types, this specifies the username to log in to the database. For some databases, this has a different meaning. For example for mSQL and mysql, its the name of the database to connect to.

 
# For mSQL, its ignored
DBUsername whocares
# For mysql, its the name of mysql user to log in as
DBUsername mikem
# For Oracle, its the name of the Oracle user to
# log in as
DBUsername scott

6.5.4 DBAuth

Usually used by Perl DBI to specify the password for the user specified in DBUsername. For some databases, this has a different meaning. For example for mSQL, its not used at all, and can be ignored. For mysql, it's optional, depending on how you have configured your database.

 
# For mSQL, its ignored
DBAuth any old rubbish
# For mysql, its the mysql password for DBUsername
DBAuth fred
# For Oracle, its Oracle password for DBUsername
DBAuth tiger

6.5.5 AddQuery

This SQL statement is executed whenever a new user session starts (i.e. when an Accounting-Request Start message is received). It is expected to record the details of the new session in the SQL database. Special formatting characters may be used (the %{attribute} ones are probably the most useful).

It defaults to:

insert into RADONLINE (USERNAME, NASIDENTIFIER, NASPORT, \
ACCTSESSIONID, TIME_STAMP, FRAMEDADDRESS, PORTTYPE, \
SERVICETYPE) values ('%n', '%N', %{NAS-Port}, '%{Acct-Session-Id}', \
%{Timestamp}, '%{Framed-IP-Address}', '%{Port-Type}', '%{Service-Type}')

6.5.6 DeleteQuery

This SQL statement is executed whenever a user session finishes (i.e. when an Accounting-Request Stop message is received). It is expected to remove the details of the session from the SQL database. Special formatting characters may be used (the %{attribute} ones are probably the most useful).

It defaults to:

delete from RADONLINE where USERNAME='%n' and \
NASIDENTIFIER='%N' and NASPORT=%{NAS-Port}

6.5.7 ClearNasQuery

This SQL statement is executed whenever a NAS reboot is detected. It is expected to clear the details of all sessions on that NAS from the SQL database. Special formatting characters may be used (the %{attribute} ones are probably the most useful).

It defaults to:

delete from RADONLINE where NASIDENTIFIER='%N'

6.5.8 CountQuery

This SQL statement is executed whenever a Simultaneous-Use check item or MaxSessions must be checked during an Access-Request. It is expected to find and return details of all the user sessions currently in the Session Database for the given User-Name. For each entry, it is expected to return the NAS-Identifier, NAS-Port and Acct-Session-Id (in that order) of each session currently in the Session Database. The returned rows are counted, and if there are apparently too many sessions, SessionDatabase SQL will query each NAS and port to confirm if the user is still on line at that port with that session ID.

It defaults to:

select NASIDENTIFIER, NASPORT, ACCTSESSIONID from RADONLINE \
where USERNAME='%n'

Hint : You can make SessionDatabase SQL count sessions in different ways depending on how you want to restrict your sessions. For example, you could limit the number of users permitted to log in to a particular realm with something like:

 
CountQuery select NASIDENTIFIER, NASPORT, ACCTSESSIONID from\
 RADONLINE where USERNAME like '%%@%R'

If your Session Database table included the Called-Station-Id for each session, you could limit the maximum number of users with the same Called-Station-ID with something like:

 
CountQuery select NASIDENTIFIER, NASPORT, ACCTSESSIONID from\
 RADONLINE where CALLEDSTATIONID ='%{Called-Station-Id}

6.6.1 Identifier

This optional parameter assigns a name to the Session Database, so it can be referred to in other parts of the configuration file.

 
# Here is a useful name for this Session Database
Identifier SDB1

6.6.2 Filename

Specifies the filename that holds the Session Database. Defaults to %D/online , The actual file names will depend on which DBM format Perl selects for you, but will usually be something like online.dir and online.pag in DbDir. The file name can include special formatting characters as described in Section 6.2 .

 
# Session database in called online2.* in DbDir
Filename %D/online

6.7.1 Filename

The name of the file that will be logged to. The file name can include special path name characters as defined in "Special characters in file names and other parameters" on page 8. The default is %L/logfile, i.e. a file named logfile in LogDir.

 
# Log file goes in /var/log, with year number
LogFile /var/log/%Y-radius.log

6.7.2 Trace

Defines the priority level of messages to be traced. See Section 6.3.3 .

6.8.1 Facility

The name of the syslog facility that will be logged to. The default is `user'.

 
# Log to the syslog facility called `radius'
Facility radius

6.8.2 Trace

Defines the priority level of messages to be traced. See Section 6.3.3 .

6.9.1 DBSource, DBUsername, DBAuth

These parameters specify how to connect to the database to use for logging. They need to be set in a similar way to as for <AuthBy SQL>. They specify the DBD driver, database and username to connect to.

 
# Connect to mSQL with database named `radius'
DBSource    dbi:mSQL:radius
DBUSername  
DBAuth       

6.9.2 Table

Defines the name of the SQL table to insert into. Defaults to `RADLOG'.

 
# Insert into a table called mylog
Table mylog

6.9.3 Trace

Defines the priority level of messages to be traced. See Section 6.3.3 .

6.10.1 Port

This optional parameter specifies the UDP port number that the SNMP Agent is to listen on. It defaults to 161. There should only rarely be any reason to change it. The argument may be either a numeric port number or an alphanumeric service name as specified in /etc/services (or its moral equivalent on your system).

 
# Use a non-standard port
Port 9991

6.10.2 BindAddress

This optional parameter specifies a single host address to listen for SNMP requests on. It is only useful if you are running Radiator on a multi-homed host (i.e. a host that has more than one network address). Defaults to the global value of BindAddress (usually 0.0.0.0 i.e. listen on all networks connected to the host, but see Section 6.3.6 ).

 
# Only listen on one network, not all the ones connected
BindAddress 203.63.154.0

6.10.3 Community

SNMP V1 provides a weak method of authenticating SNMP requests, using the "community name". This optional parameter allows you to specify the SNMP V1 community name that will be honored by SNMPAgent. Any SNMP request that does not include the correct community name will be ignored. Defaults to `public'. We strongly recommend that you choose a community name and keep it secret.

 
# Use a secret community.
Community mysnmpsecret

6.12.1 RewriteUsername

This parameter enables you to alter the user name in authentication and accounting requests before they are handled by the Realm. See Section 14.0 .

You can have any number of RewriteUsername parameters in a Realm or Handler. The rewrites will be applied to the user name in the same order that they appear in the configuration file. The rewrites are applied after any global or per-Client rewrites. At Trace level 4, you can see the result of each separate rewrite for debugging purposes.

RewriteUsername will be ignored if there is a RewriteFunction defined for this Realm or Handler.

 
# Strip the realm from all requests, because our
# database only has user names (no realm)
RewriteUsername	     s/^([^@]+).*/$1/

# Translate all uppercase to lowercase
RewriteUsername   tr/A-Z/a-z/

6.12.2 RewriteFunction

This optional parameter allows you to define you own special Perl function to rewrite user names. You can define an arbitrarily complex Perl function that might call external programs, search in databases or whatever. The username is changed to whatever is returned by this function.

If you define a RewriteFunction for a Realm or Handler, it will be used in preference to RewriteUsername. RewriteUsername will be ignored for that Realm or Handler.

 
# Strip out NULs, trailing realms, translate to
# lower case and remove single quotes
RewriteFunction sub { my($a) = shift; $a =~ s/[\000]//g; $a =~ s/^([^@]+).*/$1/; $a =~ tr/[A-Z]/[a-z]/; $a =~ s/'//g; $a; }

6.12.3 MaxSessions

This parameter allows you to apply a simple limit to the number of simultaneous sessions a user in this Realm is permitted to have. It is most common to limit users to either one session at a time or unlimited, but Radiator also supports other numbers.

MaxSessions works by looking at each accounting request for a realm when it arrives. whenever a Start is seen for a user, the count of their number if current sessions is incremented, and whenever a Stop is seen, it is decremented. When an access request is received, the number of sessions current for that user is compared to MaxSessions. If the user already has MaxSessions sessions or more, Radiator replies with an access denial. By setting MaxSessions to 0, you can temporarily deny access to all users in the realm.

You can control the maximum number of sessions on a per-user basis with the Simultaneous-Use check item (see Section 13.1.12 ).

The session count for each user is stored entirely within Radiator (unless you specify a SessionDatabase clause). This means that if you restart or reinitialise Radiator, it will lose count of the number of current sessions for each user. Radiator can use SNMP to confirm whether a user is already logged in or not (see Section 6.4.5 ).

You should note that if Radiator fails to receive an accounting Stop request, it might result in incorrectly thinking the user is not permitted to log in when in fact they are. You can correct this by restarting Radiator, or by sending an artificial accounting stop for the user using the radpwtst utility (see Section 8.0 ) or by configuring Radiator to query the NAS directly (see Section 6.4.5 ).

 
# Limit all users in this realm to max of 1 session
MaxSessions 1

6.12.4 AcctLogFileName

The names of the files used to log Accounting-Request message in the standard radius accounting log format. All Accounting-Request messages will be logged to the files, regardless of their Acct-Status-Type. The log file format is described in Section 15.5 . If no AcctLogFileName is defined, accounting messages will not be logged for this realm. The default is no logging. The file name can include special formatting characters as described in Section 6.2 , which means that using the %C, %c and %R specifiers, you can maintain separate accounting log files for each Realm or Client or a combination. The AcctLogFileName files are always opened written and closed for each message, so you can safely rotate them at any time.

If the AuthBy module you select does no special accounting logging, you may want to enable this parameter for the Realm. Note that logging to AcctLogFileName is in addition to any recording that a specific AuthBy module might do (such as, say, AuthBy SQL). The username that is recorded in the log file is the rewritten user name when RewriteUsername is enabled.

You can specify any number of AcctLogFileName parameters. Each one will result in a separate accounting log file.

Hint: You can change the logging format with AcctLogFileFormat

 
# Log all accounting to a single log file in LogDir
AcctLogFileName %L/details

6.12.5 AcctLogFileFormat

This optional parameter is used to alter the format of the accounting log file from the standard radius format. AcctLogFileFormat is a string containing special formatting characters. It specifies the format for each line to be printed to the accounting log file. A newline will be automatically appended. It is most useful if you use the %{attribute} style of formatting characters (to print the value of the attributes in the current packet.

 
AcctLogFileFormat %{Timestamp} %{Acct-Session-Id}\
 %{User-Name}

6.12.6 WtmpFileName

The name of a Unix SVR4 wtmp format file to log Accounting-Request messages. All Accounting-Request messages will be logged. If WtmpFileName is not defined, no messages will be logged in this format. The default is no logging. The file name can include special formatting characters as described in Section 4.2 on page 4, which means that using the %C, %c and %R specifiers, you can maintain separate accounting log files for each Realm or Client or a combination. The WtmpFileName file is always opened written and closed for each message, so you can safely rotate it at any time. Start messages are logged as USER_PROCESS (7), all other messages are logged as DEAD_PROCESS (8).

You may wish to use your standard Unix administration tools to process information in the wtmp file.

6.12.7 PasswordLogFileName

The name of file to log all authentication attempts to. The default is no logging. The file name can include special formatting characters as described in Section 4.2 on page 4, which means that using the %C, %c and %R specifiers, you can maintain separate password log files for each Realm or Client or a combination.

Each login attempt that generates a password check will be logged to the file, one attempt per line. The file format is described in Section 15.5 .

 
# Help desk want to see all password attempts
PasswordLogFileName %L/password.log

6.12.8 ExcludeFromPasswordLog

For security reasons, you can exclude certain users from the passwords logged to PasswordLogFileName. The value is a white space separated list of user names.

 
# Dont log password from our sysadmin or root
ExcludeFromPasswordLog root admin ceo nocboss

6.12.9 AccountingHandled

Forces Radiator to acknowledge Accounting requests, even if the AuthBy modules for the Realm would have normally ignored the request. This is useful if you don't really want to record Accounting requests, but your NAS keeps retransmitting unless it gets an acknowledgment.

 
# My AuthBy SQL ignores accounting
AccountingHandled

6.12.10 PreAuthHook

This optional parameter allows you to define a Perl function that will be called during packet processing. PreAuthHook is called for each request after per-Realm username rewriting and before it is passed to any AuthBy clauses. A reference to the current request is passed as the first argument, and a reference to the reply packet currently being constructed is passed as the second argument

The hook code is compiled by Perl when Radiator starts up. Compilation errors in your hook code will be reported to the log file at start-up time. Runtime errors in your hook will also be reported to the log file when your hook executes. Multiline hooks (i.e. with trailing backslashes (\)) are parsed by Radiator into one long line. Therefore you should not use trailing comments in your hook.

PreAuthHook Can be an arbitrarily complicated Perl function, that might run external processes, consult databases, change the contents of the current request or many other things.

 
# Fake a new attribute into the request
PreAuthHook sub { ${$_[0]}->add_attr(`test-attr', \
                 `test-value');}

6.12.11 PostAuthHook

This optional parameter allows you to define a Perl function that will be called during packet processing. PostAuthHook is called for each request after it has been passed to all the AuthBy clauses. A reference to the current request is passed as the first argument, and a reference to the reply packet currently being constructed is passed as the second argument. The third argument is the result of the authentication ($main::ACCEPT, $main::REJECT etc.).

The hook code is compiled by Perl when Radiator starts up. Compilation errors in your hook code will be reported to the log file at start-up time. Runtime errors in your hook will also be reported to the log file when your hook executes. Multiline hooks (i.e. with trailing backslashes (\)) are parsed by Radiator into one long line. Therefore you should not use trailing comments in your hook.

PostAuthHook Can be an arbitrarily complicated Perl function, that might run external processes, consult databases, change the contents of the current request or many other things.

 
# Add some reply attributes to the reply message
# if it is a REJECT and there is 1 or fewer there already
PostAuthHook sub { ${$_[1]}->add_attr(`test-attr', \
                    `test-value') \
                      	 if ${$_[2]} == $main::REJECT \
							   && ${$_[1]}->attr_count() <= 1; }

6.12.12 AuthByPolicy

Allows you to control how multiple AuthBy clauses in this Handler or Realm will be used. See section Section 6.18.1 .

6.12.13 AuthBy

This specifies that the Handler is to be authenticated with an <AuthBy> clause that is defined elsewhere. The argument must specify the Identifier of the AuthBy clause to use. The AuthBy Clause may be defined anywhere else: at the top level, or in a Realm or Handler clause. You can have as many AuthBy parameters as you wish. They will be used in the order that they appear in the configuration file (subject to AuthByPolicy) in the same was ay <AuthBy > clauses.

Hint . This is a convenient way to reuse the same authenticator for many Realms or Handlers.

 
<AuthBy xxxxx>
	Identifier myidentifier
</AuthBy>
<Realm xxxx>
	# This authenticates through the AuthBy defined above
	AuthBy myidentifier
</Realm>

6.12.14 <AuthBy xxxxxx>

This marks the beginning of an AuthBy clause in a Handler or Realm, which defines how to authenticate and record accounting information for all the users in this Realm or Handler. The xxxxxx is the name of a specific AuthBy module. See the following sections for how to configure specific AuthBy clauses.

<AuthBy xxxx> both defines an authentication method and specifies where it should be used.

Note that something like

 
<Realm xxxx>
	<AuthBy xxxxx>
		....
	<AuthBy>
	....
</Realm>

Is identical to

 
<AuthBy xxxxx>
	Identifier myidentifier
</AuthBy>
<Realm xxxx>
	# This authenticates through the AuthBy defined above
	AuthBy myidentifier
</Realm>

6.13.1 Fork

The parameter forces the authentication module to fork(2) before handling the request. Fork should only be set if the authentication module or the way you have it configured is "slow" i.e. takes more than a fraction of a second to process the request.

If you don't understand what forking is for or how it can improve the performance of your Radiator server, talk about it to someone who does before using it. Not all authentication methods will benefit from forking. Fork has no effect on Win95, Win98 or NT.

Technical Note: In particular, it does not usually make sense to use Fork with AuthBy SQL, AuthBy FILE, AuthBy LDAP or any of the other common authentication methods provided with Radiator. Further, some SQL and LDAP client libraries are not robust across forks. You might want to consider using Fork with AuthBy EXTERNAL or a custom authentication module if it needs to do significant amounts of IO, or to communicate with a remote system.

 
# This AuthBy EXTERNAL program is very slow, and does lots of IO
Fork

6.13.2 UseAddressHint

This optional parameter forces Radiator to honour a Framed-IP-Address in an Access-Request request unless it is overridden by a Framed-IP-Address in the users reply items. If you enable this, then users will get the IP Address they ask for. If there is a Framed-IP-Address reply item for a user, that will override anything they might request.

 
# Let users get addresses they ask for
UseAddressHint

6.13.3 DynamicReply

This optional parameter specifies a reply item that will be eligible for run-time variable substitution. That means that you can use any of the % substitutions in Table 1 in that reply item. You can specify any number of DynamicReply lines, one for each reply item you want to do replacements on. Any packet-specific replacement values will come from the Access-Accept message being constructed, and not from the incoming Access-Request. That means that special characters like %n will not be replaced by the received User-Name, because User-Name is in the request, but not the reply.

In the following example, substitution is enabled for USR-IP-Input-Filter. When a user authenticates, the %a in the filter will be replaced by the users IP Address, which makes the filter an anti-spoof filter.

 
<AuthBy whatever>
       ......
       UseAddressHint
       DynamicReply USR-IP-Input-Filter
</AuthBy>

In the users file:

 
DEFAULT User-Password = "UNIX"
    Framed-IP-Address = 255.255.255.254,
    Framed-Routing = None,
    Framed-IP-Netmask = 255.255.255.255,
    USR-IP-Input-Filter = "1 REJECT src-addr != %a;",
    Service-Type = Framed-User

Technical Note: this parameter used to be called "Dynamic". That name is still recognized as a synonym for "DynamicReply".

6.13.4 DynamicCheck

This optional parameter specifies a check item that will be eligible for run-time variable substitution prior to authentication. That means that you can use any of the % substitutions in Table 1 in that check item. You can specify any number of DynamicCheck lines, one for each check item you want to do replacements on.

In the following example, substitution is enabled for the Group check item. When a user authenticates, the %{Shiva-VPN-Group} in the check item will be replaced with the value of the Shiva-VPN-Group attribute in the authentication request. You could use this mechanism to verify that the user is in the Unix group corresponding to their Shiva-VPN-Group.

 
<AuthBy whatever>
       ......
       DynamicCheck Group
</AuthBy>

In the users file:

 
DEFAULT Group=%{Shiva-VPN-Group}
    Framed-IP-Address = 255.255.255.254,
    Framed-Routing = None,
    Framed-IP-Netmask = 255.255.255.255,
    ........

6.13.5 Identifier

This allows you to assign a symbolic name to an AuthBy clause and its configuration. This allows you to refer to it by name in an Auth-Type check item when authenticating a user.

The most common use of this is to create a "System" authenticator, typically with an <AuthBy UNIX> clause. A typical example configuration file that uses this feature might be:

 
<Realm DEFAULT>
 	<AuthBy FILE>
 	</AuthBy>
</Realm>
<AuthBy UNIX>
	Identifier System
</AuthBy>

You can then have something like this in your users file:

 
DEFAULT Auth-Type = System
        Framed-IP-Netmask .....

 
        ...........

In this example, all users in all realms will match the DEFAULT user in the users file. This will in turn check their username and password against a UNIX password file as configured by the AuthBy UNIX clause in the configuration file. If the password checks out, they will get the Radius attributes specified in the second and subsequent lines of the DEFAULT user entry in the users file.

6.13.6 StripFromReply

Strips the named attributes from Access-Accepts before replying to the originating client. The value is a comma separated list of attribute names. StripFromReply removes attributes from the reply before AddToReply adds any to the reply. There is no default. This is most useful with AuthBy RADIUS to prevent downstream Radius servers sending attributes you don't like back to your NAS.

 
# Remove dangerous attributes from the reply
StripFromReply Framed-IP-Netmask,Framed-Compression

6.13.7 AddToReply

Adds attributes to Access-Accepts before replying to the originating client. Value is a list of comma separated attribute value pairs all on one line, exactly as for any reply item. StripFromReply removes attributes from the reply before AddToReply adds any to the reply. You can use any of the special % formats in the attribute values. There is no default.

Although this parameter can be used in any AuthBy method, it is most useful in methods like AuthBy UNIX and AuthBy NT, which don't have a way of specifying per-user reply items.

 
# Append some necessary attributes for our pops
AddToReply cisco-avpair="ip:addr_pool=mypool"

6.13.8 DefaultReply

This is similar to AddToReply ( Section 6.13.7 ) except it adds attributes to an Access-Accept only if there would otherwise be no reply attributes. StripFromReply will never remove any attributes added by DefaultReply. Value is a list of comma separated attribute value pairs all on one line, exactly as for any reply item. You can use any of the special % formats in the attribute values. There is no default.

Although this parameter can be used in any AuthBy method, it is most useful in methods like AuthBy UNIX, AuthBy NT and AuthBy SYSTEM, which don't have a way of specifying per-user reply items. In other AuthBy methods you can also very easily set up a standard set of reply items for all users, yet you can still override reply items on a per-user basis.

 
# If the user had no reply items set some
DefaultReply Service-Type=Framed,Framed-Protocol=PPP

6.13.9 FramedGroup

This optional parameter acts similarly to Framed-Group reply items, but it applies to all Access-Requests authenticated by this AuthBy clause. If FramedGroup is set and a matching FramedGroupBaseAddress is set in the Client from where the request came, then a Framed-IP-Address reply item is automatically calculated by adding the NAS-Port in the request to the FramedGroupBaseAddress specified by FramedGroup. See Section 6.4.7 for more details.

Hint: you can override the value of FramedGroup for a single user by setting a Framed-Group reply item for the user.

 
# Work out the users IP address from the first 
# FramedGroupBaseAddress specified in out client
FramedGroup 0

6.13.10 NoDefaultIfFound

Normally if Radiator searches for a user in the database and finds one, but the users check items fail, Radiator will then consult the DEFAULT user entry. However, if the NoDefaultIfFound parameter is set, Radiator will only look for a DEFAULT if there were no entries found in the user database for the user.

 
# don't fall through to DEFAULT if a users check item failed
NoDefaultIfFound

6.13.11 DefaultSimultaneousUse

This optional parameter defines a default value for Simultaneous-Use check items that will apply only if the user does not have their own user-specific Simultaneous-Use check item.

 
# Use sim-use of 2 unless there is a user-specific entry
DefaultSimultaneousUse 2

6.15.1 Filename

Specifies the filename that holds the user database. Defaults to %D/users , i.e. a file named users in DbDir. The file name can include special formatting characters as described in Section 6.2 .

 
# user database in called rad_users in DbDir
Filename %D/rad_users

6.15.2 Nocache

Disables caching of the user database, and forces Filename to be reread for every Authentication. If not set, AuthBy FILE will only reread the user database when the files modification time changes. Don't use this parameter unless you have to, because it can be very slow for any more than 1000 users or so. If you need think you need Nocache , you should consider DBFILE instead.

 
# Don't cache so we can do some simple testing
# without restarting the server all the time
Nocache

6.15.3 AcceptIfMissing

Normally, if a user is not present in the database file, they will always be rejected. If this optional parameter is set, and a user is not in the database file they will be unconditionally accepted . If they are in the database file, they will be accepted if and only if their check items pass in the normal way.

This option is usually only useful in conjunction with a following AuthBy that will actually check all passwords. It can therefore be used to impose additional checks on a subset of your user population.

Technical Note: it won't automatically accept DEFAULT users.

 
# Apply some extra checks for those users in the users file, 
# then authenticate them with PLATYPUS
<Realm xxx>
	AuthByPolicy ContinueWhileAccept
	<AuthBy FILE>
		AcceptIfMissing
		Filename %D/users
	</AuthBy>
	<AuthBy PLATYPUS>
		# whatever
	</AuthBy>
</Realm>

6.16.1 Filename

Specifies the filename that holds the user database. Defaults to %D/users , i.e. files named users.dir and users.pag in DbDir. The file name can include special formatting characters as described in Section 6.2 . Depending on the actual DBM module that Perl chooses, the database files may have other extensions.

 
# user database in called rad_users in DbDir
Filename %D/rad_users

6.16.2 AcceptIfMissing

Normally, if a user is not present in the database file, they will always be rejected. If this optional parameter is set, and a user is not in the database file they will be unconditionally accepted . If they are in the database file, they will be accepted if and only if their check items pass in the normal way.

This option is usually only useful in conjunction with a following AuthBy that will actually check all passwords. It can therefore be used to impose additional checks on a subset of your user population.

Technical Note: it won't automatically accept DEFAULT users.

 
# Apply some extra checks for those users in the users file, 
# then authenticate them with PLATYPUS
<Realm xxx>
	AuthByPolicy ContinueAlways
	<AuthBy DBFILE>
		AcceptIfMissing
		Filename %D/users
	</AuthBy>
	<AuthBy PLATYPUS>
		# whatever
	</AuthBy>
</Realm>

6.17.1 Filename

Specifies the filename that holds the user database. Defaults to %D/users.cdb . The file name can include special formatting characters as described in Section 6.2 .

 
# user database in called rad_users.cdb in DbDir
Filename %D/rad_users.cdb

6.17.2 AcceptIfMissing

Normally, if a user is not present in the database file, they will always be rejected. If this optional parameter is set, and a user is not in the database file they will be unconditionally accepted . If they are in the database file, they will be accepted if and only if their check items pass in the normal way.

This option is usually only useful in conjunction with a following AuthBy that will actually check all passwords. It can therefore be used to impose additional checks on a subset of your user population.

Technical Note: it won't automatically accept DEFAULT users.

 
# Apply some extra checks for those users in the users file, 
# then authenticate them with PLATYPUS
<Realm xxx>
	AuthByPolicy ContinueAlways
	<AuthBy CDB>
		AcceptIfMissing
		Filename %D/users.cdb
	</AuthBy>
	<AuthBy PLATYPUS>
		# whatever
	</AuthBy>
</Realm>

6.18.1 AuthByPolicy

This parameter allows you to control the behaviour of multiple AuthBy clauses inside this AuthBy GROUP. In particular, it allows you to specify under what conditions Radiator will try the next AuthBy clause. If you only have one AuthBy clause, AuthByPolicy is not relevant and is ignored.

Recall that for a single Realm, Handler or AuthBy GROUP, you can specify more than one AuthBy clause. The normal behaviour of Radiator is to try to authenticate with the first one. If that authentication method either Accepts or Rejects the request, then Radiator will immediately send a reply to the NAS. If on the other hand the AuthBy Ignores the request, then the next one will be tried. That is the normal and default behaviour, but with AuthByPolicy, you can change that. The permissible values of AuthByPolicy are:

• ContinueWhileIgnore

This is the default. Continue trying to authenticate until either Accept or Reject

• ContinueUntilIgnore

Continue trying to authenticate until Ignore

• ContinueWhileAccept

Continue trying to authenticate as long as it is Accepted

• ContinueUntilAccept

Continue trying to authenticate until it is Accepted

• ContinueWhileReject

Continue trying to authenticate as long as it is Rejected

• ContinueUntilReject

Continue trying to authenticate until it is Rejected

• anything else

Always do every authentication method.

 
# Authenticate with SQL, but if they are rejected 
# fall back to a flat file
AuthByPolicy ContinueWhileReject
<AuthBy SQL>
    ....
</AuthBy>
<AuthBy FILE>
    ....
</AuthBy>

You should note that you can only have one AuthByPolicy parameter, and it applies to all the AuthBys. You cant change it between one AuthBy clause and another.

6.18.2 RewriteUsername

This parameter enables you to alter the user name in authentication and accounting requests before they are passed to any of the AuthBy clauses in this group. See Section 14.0 .

You can have any number of RewriteUsername parameters in a group. The rewrites will be applied to the user name in the same order that they appear in the configuration file. At Trace level 4, you can see the result of each separate rewrite for debugging purposes.

 
# Strip the realm from all requests, because our
# database only has user names (no realm)
RewriteUsername	     s/^([^@]+).*/$1/

# Translate all uppercase to lowercase
RewriteUsername   tr/A-Z/a-z/

6.19.1 Debug

Debug causes the operation of the iPASS libraries to be traced. The output is usually in /usr/ipass/logs/iprd.trace unless you change it with the Trace parameter. Optional.

 
# Trace operation of the iPASS library
Debug

6.19.2 Config

Sets the location of the iPASS configuration file. Defaults to /usr/ipass/ipass.conf . You can use the special filename formats. Optional.

 
		Config /usr/local/ipass/ipass.conf

6.19.3 Trace

Sets the location of the iPASS trace file. Defaults to /usr/ipass/logs/iprd.trace . You can use the special filename formats. Optional.

 
Trace	   /usr/local/ipass/logs/iprd.trace

6.19.4 Home

Sets the location of the iPASS installation directory for locating SSL certificate and key files. Defaults to /usr/ipass . You can use the special filename formats.

 
		Home   /usr/local/ipass

6.20.1 Filename

Specifies the filename of the password file. Defaults to / etc/passwd . The file name can include special formatting characters as described in Section 6.2 .

Hint: On systems with shadow password files, such as Solaris, Filename can name the shadow file. In order to support this, Radiator must have permission to read the shadow file (this usually means it must run as root).

 
# password file is in /usr/local/etc/local_passwd
Filename /usr/local/etc/local_passwd

6.20.2 Match

This parameter allows you to use flat files with different formats to the standard Unix password format. Match is a regular expression that is expected to match and extract the username, password and (optional) primary group ID fields from each line in the password file. The default extracts the first two colon separated fields as username and password, followed by a UID, followed by an (optional) primary group ID (i.e. standard Unix password file format).

 
# fields are separated by vertical bar |
Match ^([^\|]*)\|([^\|]*)

Hint. The default Match expression is:

 
Match ^([^:]*):([^:]*):?[^:]*:?([^:]*)

6.20.3 GroupFilename

Specifies the name of the group file. The group file is in standard Unix group file format. Used to check "Group=" check items when authentication is cascaded from another module. Defaults to /etc/group.

 
# group file is in /usr/local/etc/local_group
GroupFilename /usr/local/etc/local_group

6.20.4 Nocache

Disables caching of the password and group files, and forces them to be reread for every Authentication. If not set, AuthBy UNIX will only reread the files when their modification time changes. Don't use this parameter unless you have to, because it can be very slow for any more than 1000 users or so.

 
# Don't cache so we can do some simple testing
# without restarting the server all the time
Nocache

6.21.1 Command

Specifies the command to run. The command can include special formatting characters as described in Section 6.2 . There is no default, and a Command must be specified. See above for details of how stdin, stdout and exit status are interpreted.

 
# Interface to an external system
Command /usr/local/bin/doReq %T

6.21.2 DecryptPassword

This optional parameter makes AuthBy EXTERNAL decrypt the User-Password attribute before passing it to the external program. If you don't specify this, User-Password will be passed exactly as received in the request (i.e. encrypted by MD5 according to the Radius standard).

This is not able to decrypt CHAP passwords.

 
# Pass plaintext passwords to the external program
DecryptPassword

6.22.1 Domain

Specifies the name of the NT user domain that is to be checked for the user name and password (this is not necessarily the same as a DNS domain). The Domain Controller for the Domain you specify is consulted for account details, passwords and Group membership. The default for Domain is undefined, which means (on NT) to check passwords for the default domain for the host where Radiator is running. When running Radiator on Unix, you must specify the Domain.

 
# Look in a special domain for passwords & groups
Domain admin

6.22.2 DomainController

This optional parameter allows you to specify the name of your Domain Controller. If you don't specify DomainController when running Radiator on NT, Radiator will attempt to determine the name of your Domain Controller by polling the network. You would not normally need to set this when running Radiator on NT.

You must set this to the host name (not the IP address) of the Primary Domain Controller when running on Unix. On Unix, you must also be sure that there is an entry for the DomainController name in DNS. You may need to add an entry to /etc/hosts.

 
# This must be a DNS or host name, _not_ an IP address
DomainController hostname

6.23.1 DBSource

This parameter is used by Perl DBI to specify the database driver and database system to connect to. It will usually begin with dbi:driver_name: . There is no standard for the text following the driver name. You will have to consult the details for your DBD driver. Some examples are given below

 
# Connect to mSQL database called radius on localhost, standard 
# port
DBSource dbi:mSQL:radius
# Or... Connect to the Oracle sid called users
DBSource dbi:Oracle:users
# Or... Connect to mysql database called radius on localhost, 
# standard port
DBSource dbi:mysql:radius

6.23.2 DBUsername

For most database types, this specifies the username to log in to the database. For some databases, this has a different meaning. For example, for mSQL its the name of the database to connect to.

 
# For mSQL, its ignored
DBUsername ignored
# For Oracle, its the name of the Oracle user to
# log in as
DBUsername scott

6.23.3 DBAuth

Usually used by Perl DBI to specify the password for the user specified in DBUsername. For some database, this has a different meaning. For example for mSQL and mysql, its not used at all, and can be ignored.

 
# For mSQL, its ignored
DBAuth any old rubbish
# For Oracle, its Oracle password for DBUsername
DBAuth tiger

6.23.4 AuthSelect

This is an SQL select statement that will be used to find and fetch the password and possibly check items and reply items for the user who is attempting to log in. You can use the special macros such as %n and others to specify the username to select. The first column returned is expected to be the password; the second is the check items (if any) and the third is the reply items (if any) (you can change this expectation with the AuthColumnDef parameter). Defaults to " select PASSWORD from SUBSCRIBERS where USERNAME='%n' ", which does not return any check or reply items. You can make arbitrarily complicated SQL statements so that you will only authenticate users for example whose account status is OK or who have not exceeded their download limit etc. See Section 13.0 for information on how check items and reply items are used. If the password (or encrypted password) column for a user is NULL in the database, then any password will be accepted for that user.

The password column may be in any of the formats described in Section 13.1.1 .

If AuthSelect is defined as an empty string, SQL will not attempt to authenticate at all.

 
# Check user status is current. No reply items in DB
# Note: The entire statement must be on one line
AuthSelect select PW, CHECK from USERS where\
      NAME='%n'and STATUS = 1

6.23.5 AuthColumnDef

This optional parameter allows you to change the way Radiator interprets the result of the AuthSelect statement. If you don't specify any AuthColumnDef parameters, Radiator will assume that the first column returned is the password; the second is the check items (if any) and the third is the reply items (if any). If you specify any AuthColumnDef parameters, Radiator will use the column definitions you provide.

You can specify any number of AuthColumnDef parameters, one for each interesting field returned by AuthSelect. The general format is:

 
AuthColumnDef n, attributename, type

• n is the index of the field in the result of AuthSelect. 0 is the first field.
• attributename is the name of the attribute to be checked or replied. The value of the attribute is in the nth field of the result. The special attributename `GENERIC' indicates that it is a list of comma separated attribute=value pairs.
• type indicates whether it is a check or reply item.

A few examples are in order:

Example 1

The standard default AuthSelect statement:

 
AuthSelect select PASSWORD from SUBSCRIBERS \
      where USERNAME='%n'

returns a single plaintext password check item. The result could be interpreted with:

 
AuthColumnDef 0, User-Password, check

Example 2

A more complicated AuthSelect statement:

 
AuthSelect select PASSWORD, CHECKATTR, REPLYATTR \
       from SUBSCRIBERS \
      where USERNAME='%n'

returns 3 fields in the result. The first is a plaintext password, the second is a string of check items like `Service-Type=Framed-User, Expiration="Feb 2 1999"`, and the third field is a string of reply items like `Framed-Protocol=PPP,Framed-IP-Netmask = 255.255.255.0,....' . The result could be interpreted with:

 
AuthColumnDef 0, User-Password, check
AuthColumnDef 1, GENERIC, check
AuthColumnDef 2, GENERIC, reply

Hint: this has the same effect as the default rule that Radiator applies if no AuthColumnDef parameters are specified at all.

Hint : if your PASSWORD column contains a Unix encrypted password and you are using AuthColumnDef, you will need to set it like this:

 
AuthColumnDef 0, Encrypted-Password, check

Example 3

This AuthSelect statement:

 
AuthSelect select SERVICE, PASSWORD, MAXTIME     
       from SUBSCRIBERS \
      where USERNAME='%n'

returns 4 fields in the result. The first is a Service-Type to check, the next is a plaintext password and the last is the number of seconds to send back in Session-Timeout. The result could be interpreted with:

 
AuthColumnDef 0, Service-Type, check
AuthColumnDef 1, User-Password, check
AuthColumnDef 2, Session-Timeout, reply

6.23.6 AccountingTable

This is the name of the table that will be used to store accounting records. Defaults to "ACCOUNTING". If AccountingTable is defined to be an empty string, all accounting requests will be accepted and acknowledged, but no accounting data will be stored. You must also define at least one AcctColumnDef before accounting data will be stored.

The AccountingTable table name can contain special formatting characters: table names based on the current year and/or month might be useful, so you can rotate your accounting tables.

 
# store accounting records in RADUSAGEyyyymm table
AccountingTable RADUSAGE%Y%m

6.23.7 EncryptedPassword

This parameter should be set if and only if your AuthSelect statement will return a Unix encrypted password, and you are not using AuthColumnDef. Encrypted passwords cannot be used with CHAP authentication. If the encrypted password column for a user is NULL in the database, then any password will be accepted for that user. If the encrypted password column for a user is set to the empty string (as opposed to NULL), then no password will be accepted for that user.

Hint : This parameter ignored if you have defined your own AuthSelect column definitions with AuthColumnDef.

 
# unix Encrypted password are in CRYPTPW
AuthSelect select CRYPTPW from USERS where N = `$n'
EncryptedPassword

6.23.8 AccountingStartsOnly

If this parameter is defined, it forces AuthBy SQL to only log Accounting Start requests to the database. All other Accounting requests are accepted and acknowledged, but are not stored in the SQL database.

Hint: It does not make sense to set AccountingStartsOnly and AccountingStopsOnly.

6.23.9 AccountingStopsOnly

If this parameter is defined, it forces AuthBy SQL to only log Accounting Stop requests to the database. All other Accounting requests are accepted and acknowledged, but are not stored in the SQL database.

You may want to use this parameter if your accounting system does not use or need Accounting Start to do its billing.

 
# We only want Stops
AccountingStopsOnly

Hint: It does not make sense to set AccountingStartsOnly and AccountingStopsOnly.

6.23.10 AcctColumnDef

AcctColumnDef is used to define which attributes in accounting requests are to be inserted into AccountingTable, and it also specifies which column they are to be inserted into, and optionally the data type of that column. The general form is

 
     AcctColumnDef Column,Attribute[,Type][,Format]

Column is the name of the SQL column where the data will be inserted. Attribute is the name of the Radius attribute to store there. Type is an optional data type specifier, which specifies the data type of the SQL column. Format is an optional sprintf-style format string that will be used to format the value.

The following types are recognized:

• integer

The insertion will be done as an integer data type. Radius attributes that have VALUE names will be inserted as their integer Radius value.

• integer-date

The attribute value will be converted from Unix seconds to an SQL date in the format `Sep 3, 1995 13:37'. This is suitable for inserting the Timestamp attribute as an SQL date type. It is compatible with Microsoft SQL and Sybase datetime columns. If it is not suitable for your database, consider using formatted-date instead.

• formatted-date

The attribute will be converted by Date::Format according to the format string. You must install the Perl TimeDate package from CPAN for this to work. It is most useful for SQL databases with unusual date formats, like Oracle.

• -anything else-

Any other type string will cause the attribute to be inserted literally as a string. Quotes and other control characters will be automatically escaped to suit your database.

You can use formatted-date to create date formats to suit your SQL database. For example, this will insert the Timestamp into an Oracle date type column called TIME_STAMP:

 
AcctColumnDef	TIME_STAMP,Timestamp,formatted-date,to_date\
	('%e %m 	%Y %H:%M:%S', 'DD MM YYYY HH24:MI:SS')

This will result in a an insert statement something like this:

 
insert into ACCOUNTING(TIME_STAMP, ......) values 
(to_date('16 02 1999 16:40:02', 'DD MM YYYY HH24:MI:SS'), ....) 

For types other than formatted-date, the format field can be used to build custom values in your insert statement. This can be very useful to call SQL conversion functions on your data. If you specify a format, it will be used as a sprintf-style format, where %s will be replaced by your value.

If any named attribute is not present in the accounting request, nothing will be inserted in the column for that value. The attribute will not appear in the insert statement at all, and the SQL server's default value (usually NULL) will be used for that column. With some SQL servers, you can change the default value to be used when a column is not specified in an insert statement.

You can have 0 or more AcctColumnDef lines, one for each attribute you want to store in the accounting table. If there are no AcctColumnDef lines, then the accounting table will never be updated.

The attribute Timestamp is always available for insertion, and is set to the time the packet was received, adjusted by Acct-Delay-Time (if present), as an integer number of seconds since Midnight Jan 1 1970 UTC.

Here is an example column configuration:

 
		AcctColumnDef	 USERNAME,User-Name
		AcctColumnDef	 TIME_STAMP,Timestamp,integer
		AcctColumnDef	 ACCTSTATUSTYPE,Acct-Status-Type
		AcctColumnDef	 ACCTDELAYTIME,Acct-Delay-Time,integer
		AcctColumnDef	 ACCTINPUTOCT,Acct-Input-Octets,integer
		AcctColumnDef 	ACCTOUTPUTOCT,Acct-Output-Octets,integer
		AcctColumnDef	 ACCTSESSIONID,Acct-Session-Id
		AcctColumnDef	 ACCTSESSTIME,Acct-Session-Time,integer
		AcctColumnDef	 ACCTTERMINATECAUSE,Acct_Terminate-Cause
		AcctColumnDef	 NASIDENTIFIER,NAS-Identifier
		AcctColumnDef 	NASPORT,NAS-Port,integer

Hint: If your accounting table inserts aren't working, run Radiator at a trace level of 4, and you will see each insert statement logged before it is executed. This will help you determine if your AcctColumnDef lines are correct.

Hint: SQL table and column names are generally case sensitive, and usually can consist only of letters, digits or the underscore character `_'.

6.23.11 AcctSQLStatement

This parameter allows you to execute arbitrary SQL statements each time an accounting request is received. You might want to do it to handle processing in addition to the normal inserts defined by AcctColumnDef, or you might want to construct a much more complicated SQL statement than AcctColumnDef can handle. You only need this if the accounting definitions provided by AcctColumnDef are not powerful enough.

You can have as many AcctSQLStatement parameters as you like (i.e. 0 or more). Each one will have its special formatting macros replaced at run time (the ones of the format %{attribute-name} are probably the most useful). They are executed in the order they appear in the configuration file.

 
AcctSQLStatement delete from ONLINE where \
     SessionID='%{Acct-Session-Id}'

Hint: By having multiple AuthBy SQL clauses, and by using AccountingStartsOnly and AccountingStopsOnly, in conjunction with AcctSQLStatement, you could implement a "who is online" table.

6.23.12 Timeout

This parameter specifies a maximum period of time in seconds that we are prepared to wait for a connection or a reply from an SQL server. In the case of network failure, lost connectivity with the SQL server can mean that Radiator will wait up to this number of seconds before aborting the request. If you have specified an alternate SQL server, Radiator will then fall back to the next SQL server. Defaults to 60 seconds.

 
# Wait a maximum of 10 seconds before failing over
Timeout 10

6.24.1 Host

The host name(s) where the destination radius server is running. Can be either a DNS name or an IP address. You can specify one or more radius servers with multiple Host lines. Radiator will try up to Retries times to contact each host that you specify. If no response it heard it will try the next host in the list and so on until a reply is received or the list is exhausted.

Hint : If the DNS name for a Host resolves to multiple IP addresses, Radiator will forward to those addresses in a round-robin fashion. DNS names are resolved at startup time.

 
# Send all request for this realm to 203.63.154.2, if no reply
# try the secondary at 203.63.154.3, if no reply from that, 
# try all the addresses that radiushosts@open.com.au resolves to
# in round-robin fashion.
Host 203.63.154.2
Host 203.63.154.3
Host radiushosts@open.com.au

6.24.2 Secret

The secret we share with the destination radius server. Radiator acts like a Radius client when it forwards Radius request to another Radius server.

You must define a shared secret for each AuthBy RADIUS, and it must match the secret configured into the destination Radius server. There is no default. The secret can be any number of ASCII characters. Any ASCII character except newline is permitted, but it might be easier if you restrict yourself to the printable characters. For a reasonable level of security, the Secret should be at least 16 characters, and a mixture of upper and lower case, digits and punctuation. You should not use just a single recognizable word.

 
# This better agree with the server at
# eric.open.com.au or they wont understand us
<AuthBy RADIUS>
    Host eric.open.com.au
	    Secret 666obaFGkmRNs666
</AuthBy>

6.24.3 AuthPort

Specifies which UDP port on the destination Host to which Radiator will send authentication requests. The argument may be either a numeric port number or an alphanumeric service name as specified in /etc/services (or its moral equivalent on your system). The default port is 1645. Note that the officially assigned port number for Radius accounting has recently been changed to 1812.

 
# Send authentication to port 1812 on the remote server
AuthPort 1812

6.24.4 AcctPort

Specifies which UDP port on the destination Host to which Radiator will send accounting requests. The argument may be either a numeric port number or an alphanumeric service name as specified in /etc/services (or its moral equivalent on your system). The default port is 1646. Note that the officially assigned port number for Radius accounting has recently been changed to 1813.

 
# Send accounting to port 1813 on the remote server
AcctPort 1813

6.24.5 Retries

If Radiator does not get a reply from the destination Radius server within RetryTimeout seconds, it will retransmit the request up to this number of retries. Default is 3 (which means max of 4 transmissions)

 
# Its a poor link, so lots of retries
Retries 10

6.24.6 RetryTimeout

Specifies the number of seconds to wait for a reply before retransmitting. The default is 5 seconds, which is a common value for most Radius clients. If the destination Radius server is at the end of a distant or saturated link, you may want to set this to 10 or 20 seconds

 
# Its a poor link, wait 15 seconds before retransmission
RetryTimeout 15

6.24.7 StripFromRequest

Strips the named attributes from the request before forwarding it to Host. The value is a comma separated list of attribute names. StripFromRequest removes attributes from the request before AddToRequest adds any to the request. There is no default.

 
# Remove any NAS-IP-Address,NAS-Port attributes
StripFromRequest NAS-IP-Address,NAS-Port

6.24.8 AddToRequest

Adds attributes to the request before forwarding to Host. Value is a list of comma separated attribute value pairs all on one line, exactly as for any reply item. StripFromRequest removes attributes from the request before AddToRequest adds any to the request. You can use any of the special % formats in the attribute values. There is no default.

 
# Append a Filter-ID and host name
AddToRequest Calling-Station-Id=1,Login-IP-Host=%h

6.24.9 NoForwardAuthentication

Stops AuthBy RADIUS forwarding Authentication-Requests. They are just ACCEPTED.

 
# Just accept Authentication-Requests, don't forward them
NoForwardAuthentication

6.24.10 NoForwardAccounting

Stops AuthBy RADIUS forwarding Accounting-Requests. They are just ACCEPTED.

 
# Just accept Accounting-Requests, don't forward them
NoForwardAccounting

6.24.11 LocalAddress

This optional parameter specifies the local address to bind the proxy forwarding socket. Defaults to BindAddress (which defaults to 0.0.0.0, i.e. any address). This is usually only useful for multi-homed hosts. If you don't understand what this is for, don't set it: the default behaviour is fine for most situations.

 
# We are multi-homed, bind the proxy port so forwarded requests
# come from 203.53.154.27
LocalAddress 203.53.154.27

6.24.12 ReplyHook

This optional parameter allows you to define a Perl function that will be called after a reply is received from the remote Radius server and before it is relayed back to the original client. A reference to the original request is passed as the first argument, and a reference to the reply packet just received is passed as the second argument

The hook code is compiled by Perl when Radiator starts up. Compilation errors in your hook code will be reported to the log file at start-up time. Runtime errors in your hook will also be reported to the log file when your hook executes. Multiline hooks (i.e. with trailing backslashes (\)) are parsed by Radiator into one long line. Therefore you should not use trailing comments in your hook.

ReplyHook Can be an arbitrarily complicated Perl function, that might run external processes, consult databases, change the contents of the current request or many other things.

 
# Fake a new attribute into the reply going back to the client
ReplyHook sub { ${$_[0]}->add_attr(`test-attr', \
                 `test-value');}

6.25.1 TimeBanking

If this optional parameter is set, it will enable Time Banking, which can be used to limit the longest possible user session for the user to a pre-paid limit. If TimeBanking is enabled and if the "subaccounts.timeleft" column for the user is not NULL, then Radiator will use it to generate a Session-Timeout reply attribute. This has the effect of limiting the user session to the number of minutes specified in the subaccounts.timeleft column.

6.25.2 AddATDefaults

If this optional parameter is defined, then the account-type-specific Radius reply items will be used unless there was a user-specific reply item. This allows you to use the account-specific reply items as defaults.

6.26.1 DBSource, DBUsername, DBAuth

These parameters need to be set in exactly the same way as for <AuthBy SQL>. They specify the DBD driver, database and username to connect to. For connecting to the Platypus Microsoft SQL database by ODBC, you will usually want something like this:

 
# Connect to MSSQL with system DSN name MySystemName
DBSource    dbi:ODBC:MySystemName
DBUSername  platuser
DBAuth     platpassword

6.26.2 AccountingTable

This optional parameter specifies the name of the Platypus table to insert Accounting Stop requests into. It defaults to "radiusdat" which is the usual name for that table in Platypus. You will normally not want to change it. If you change it to the empty string, Radiator will not store any Accounting requests to Platypus at all.

 
# don't store any accounting data to platypus
AccountingTable 

6.26.3 AcctColumnDef

By default, AuthBy PLATYPUS only logs a few attributes to AccountingTable: user name, call start time, call end time and session ID. You can log additional attributes from Accounting Stop requests with AcctColumnDef in the same was as AuthBy SQL. See Section 6.23.10 for syntax. You must add the appropriate new columns to your AccountingTable before you can log to them.

 
# Log some extra data from each Stop
AcctColumnDef	NASIDENTIFIER,NAS-Identifier
AcctColumnDef	ACCTTERMINATECAUSE,Acct-Terminate-Cause

6.28.1 Host

This is the name of the LDAP host to connect to. Defaults to localhost .

 
# Connect to UMICH
Host ldap.itd.umich.edu

6.28.2 Port

Specifies the port to connect to on the LDAP host. Defaults to 389, the standard port for unencrypted LDAP. If UseSSL is specified, it defaults to 636, the standard port for encrypted LDAP. Can be a numeric port number or a symbolic service name from /etc/services or its equivalent on your system. You should never need to override the defaults.

 
# Connect using the SSL encrypted port
Port 636

6.28.3 UseSSL

This optional parameter specifies to use SSL to connect to the LDAP server, and the name of your certificate database file. It is only available with Netscape SDK based clients and the Netscape LDAP server. The database must either be the cert5.db certificate database used by Netscape Navigator 3.x or the ServerCert.db certificate database used by Netscape 2.x servers. You can use special filename characters in the filename.

UseSSL is not supported with LDAP2.

 
# Enable SSL and tell it where to find certificates
UseSSL /.netscape/cert5.db

6.28.4 AuthDN

This is the optional name to use to authenticate this Radiator server to the LDAP server. You only need to specify this if the LDAP server requires authentication from its clients. Netscape SuiteSpot servers almost always require this to be set.

 
# Log in to LDAP as admin
AuthDn admin

6.28.5 AuthPassword

This is the optional password to use to authenticate this Radiator server to the LDAP server. You only need to specify this if the LDAP server requires authentication from its clients, and you specify AuthDN. Netscape SuiteSpot servers almost always require this to be set.

 
# log in to LDAP with password adminpassword
AuthPassword adminpassword

6.28.6 BaseDN

This is the base DN where searches will be made. For each authentication request, Radiator does a SUBTREE search starting at BaseDN, looking for a UsernameAttr that exactly matches the user name in the radius request (possibly after username rewriting).

 
# Start looking here
BaseDN o=University of Michigan, c=US

6.28.7 UsernameAttr

This is the name of the LDAP attribute that is required to match the username in the authentication request (possibly after username rewriting by RewriteUsername). Defaults to "uid". The LDAP search filter is constructed from UsernameAttr and the name of the user in the Access-Request like this: "(UsernameAttr = username)" For example, if you UsernameAttr is "uid", and user "mikem" tries to log in, Radiator will use the LDAP filter "(uid=mikem)".

 
# Use the uid attribute to match usernames
UsernameAttr uid

6.28.8 PasswordAttr

This is the name of the LDAP attribute that contains the password for the user. The password may be in any of the formats supported by User-Password as described in Section 13.1.1 . Most LDAP servers will only have a plaintext password if they are secured in another way, and probably not even then. You must specify either PasswordAttr or EncryptedPasswordAttr. There is no default.

 
# Plaintext passwords. Gasp
PasswordAttr passwd

6.28.9 EncryptedPasswordAttr

This is the optional name of the LDAP attribute that contains a Unix crypt(3) encrypted password for the user. If you specify EncryptedPasswordAttr, it will be used instead of PasswordAttr, and PasswordAttr will not be fetched. You must specify either PasswordAttr or EncryptedPasswordAttr. There is no default.

Hint : If your passwords are in the form {crypt}1xMKc0GIVUNbE or {S HA}0DPiKuNIrrVmD8IUCuw1hQxNqZc=, you should be using PasswordAttr, not EncryptedPasswordAttr. Only use EncryptedPasswordAttr if the your password are plain old Unix crypt format, like: 1xMKc0GIVUNbE .

 
# Get the encrypted password from cryptpw
EncryptedPasswordAttr cryptpw

6.28.10 CheckAttr

This is the optional name of the LDAP attribute that contains the Radius check items for the user. During authentication, all the check items in this LDAP attribute (if specified) will be matched against the Radius attributes in the authentication request in the same was as for AuthBy FILE and AuthBy SQL, including Expiration in the format "Dec 08 1998". Defaults to undefined. See Section 13.1 for information on how check items are used.

Hint: If there are multiple instances of the LDAP attribute for the user, they are concatenated together with commas. This means that you can have each Radius check attribute in its own LDAP attribute for easy reading and maintenance.

 
# Check the radius items in checkitems
CheckAttr checkitems

6.28.11 ReplyAttr

This is the optional name of the LDAP attribute that contains the Radius reply items for the user. If the user authenticates successfully, all the Radius attributes named in this LDAP attribute will be returned to the user in the Access-Accept message. Defaults to undefined. See Section 13.2 for information on how reply items are used.

Hint: If there are multiple instances of the LDAP attribute for the user, they are concatenated together with commas. This means that you can have each Radius reply attribute in its own LDAP attribute for easy reading and maintenance.

 
# Reply with all the items in replyitems
ReplyAttr replyitems

6.29.1 UseGetspnam

On some operating systems (notably Solaris) AuthBy SYSTEM needs this parameter to enable it to get the encrypted password from /etc/shadow or NIS+ You also need the Shadows module from ftp://dagobert.eur.nl/pub/homebrew/Shadow-0.01.tar.gz or better. Use this if you are running on Solaris, or if Radiator reports "Bad Encrypted-Password" even if you are sure the password and ther shared secret are correct.

 
# We are on Solaris, and have installed "Shadows"
UseGetspnam

6.30.1 Host

This optional parameter specifies the name of the host where the TacacsPlus server is running. It can be a DNS name or an IP address. Defaults to `localhost'.

 
Host oscar.open.com.au

6.30.2 Key

This mandatory parameter specifies the encryption key to be used to encrypt the connection to the TacacsPlus server. You must specify this. There is no default. It must match the key specified in the TacacsPlus server configuration file.

 
# There is a line saying key = mytacacskey in my tac_plus
# config file
Key mytacacskey

6.30.3 Port

This optional parameter specifies the TCP port to be used to connect to the TacacsPlus server. It can be a service name as specified in /etc/services or an integer port number. Defaults to `tacacs' (TCP port 49). You should not need to change this unless your TacasPlus server is listening on a non-standard port.

6.30.4 Timeout

This optional parameter specifies the number of seconds timeout. Defaults to 15. You would only need to change this under unusual circumstances.

6.31.1 Table

This optional parameter defines the name of the NIS+ table to search in. It defaults to passwd.org_dir which is the name of the standard password table in NIS+. You would not normally need to change this. You could define your own NIS+ table with your own table structure to authenticate from, and define the name of the table with the Table parameter. You might occasionally want to specify a table for a specific domain with Table:

 
# Use the mydomain.com password table
Table passwd.org_dir.mydomain.com

6.31.2 Query

This optional parameter specifies how users are to be located in the NIS+ table. It is a list of field=value pairs. You can use any of the special macros such as %n for the user name described in Section 6.2 . The default is [name=%n], which will find the user name in a standard NIS+ passwd table. You would only need to define this if you define your own NIS+ table to authenticate from.

 
# Use cname and type in our own special table
Query [cname=%n,type=LOCAL]

6.31.3 EncryptedPasswordField

This optional parameter specifies the name of the field in the NIS+ table that contains the encrypted password for the user. It defaults to passwd , which is the name of the password field in the standard NIS+ passwd table. Radiator will use this field as the source of the encrypted password with which to check authentication requests.

If you define any AuthFieldDef parameters, EncryptedPasswordField will be ignored completely, and you will have to define every check and reply item (including the encrypted password) with an AuthFieldDef entry.

 
# Our special table has the password in pw
EncryptedPasswordField pw

6.31.4 AuthFieldDef

This optional parameter allows you to specify precisely how the fields in the NIS+ table are to be interpreted. If any AuthFieldDef parameters are specified, EncryptedPasswordField will be completely ignored, and you will have to define every check and reply item (including the encrypted password) with an AuthFieldDef entry.

You can specify as many AuthFieldDef parameters as you like, one for each check and reply item in the NIS+ table.

You can specify any number of AuthFieldDef parameters, one for each interesting field in the NIS+ table. The general format is:

 
AuthFieldDef fieldname,attributename,type

• fieldname is the field in the NIS+ table that contains the value to check or reply. If fieldname is not present in the NIS+ table, or is empty for the user, it won't be used.
• attributename is the name of the radius attribute to be checked or replied. The special attributename `GENERIC' indicates that it is a list of comma separated attribute=value pairs, not just a single attribute
• type indicates whether it is a check or reply item.

A few examples are in order:

Example 1

The standard NIS+ passwd table contains user name and encrypted password. You can interface to such a table by having an empty AuthBy NISPLUS clause:

 
<AuthBy NISPLUS>
</AuthBy>

Just for illustration purposes, that is exactly equivalent to the following:

 
<AuthBy NISPLUS>
    Table passwd.org_dir
    Query [name=%n]
    AuthFieldDef passwd,Encrypted-Password,check
</AuthBy>

Example 2

You might define a special NIS+ table something like this: the table called "users" contains user names in the "uname" column, encrypted password in the "pw" column, and an optional IP address to use in the "address" column:

 
<AuthBy NISPLUS>
    Table users.org_dir
    Query [uname=%n]
    AuthFieldDef pw,Encrypted-Password,check
    AuthFieldDef address,Framed-IP-Address,reply
</AuthBy>

6.32.1 Service

This optional parameter specifies the PAM service to be used to authenticate the user name. If not specified, it defaults to "login".

 
# We want to use the PAM "ppp" service to authenticate our users
Service ppp

6.33.1 CountQuery

This parameter specifies an SQL query that wil be used to count the users currently online according to the SQL Session Database. Defaults to "select COUNT(*) from RADONLINE where DNIS='%{Called-Station-Id}'". AuthBy PORTLIMITCHECK will compare the results of thios query with SessionLimit in order to determine wherther the user wil be permitted to log in at all.

Hint: You must have a <SessionDatabase SQL> configured into Radiator. The Session Database must be configured to save the columns that you plan to use to group users in your CountQuery. So, if you are using the default CountQuery, your SQL Session Database must be configured to save the Called-Station-Id attribute to the DNIS column, with something like:

 
<SessionDatabase SQL>
		DBSource	dbi:mysql:radius
		DBUsername	mikem
		DBAuth		fred
	# We want to save the DNIS as well as the usual things.
	# Requires a different schema to the example RADONLINE 
	# provided
	AddQuery	insert into RADONLINE (USERNAME,\
	NASIDENTIFIER, NASPORT, ACCTSESSIONID, TIME_STAMP,\
	FRAMEDIPADDRESS, NASPORTTYPE, SERVICETYPE, DNIS) \
	values ('%n', '%N',\
	%{NAS-Port}, '%{Acct-Session-Id}', %{Timestamp},\
	'%{Framed-IP-Address}', '%{NAS-Port-Type}', \
	'%{Service-Type}', '%{Called-Station-Id}')
</SessionDatabase>

6.33.2 SessionLimit

This parameter specifies the absolute upper limit to the number of current logins permitted to this group of users. Defaults to 0. For example if SessionLimit is set to 10, then up to 10 concurrent sessions are permitted. If an 11th user attempts to log in through this AuthBy, they will be rejected.

 
# They have paid for 20 ports
SessionLimit	20

6.33.3 ClassForSessionLimit

This optional parameter allows you to set up different charging bands for different levels of port occupancy in this group of users. You can have one or more ClassForSessionLimit lines. If the current level of port usage is below a ClassForSessionLimit, then the class name will be applied as a Class attribute to that session. Your NAS will then tag all accounting records for that session with the Class attribute. If your billing system records and uses the Class attribute in accounting records, then you could use this to charge differently for different levels of port occupancy.

 
# The first 2 users will be tagged with a Class of "normal"
# the next 2 with "overflow". No more than 4 concurrent users
# permitted
SessionLimit 4
ClassForSessionLimit normal,2
ClassForSessionLimit overflow,4

FIGURE 1. radpwtst Graphical User Interface

FIGURE 2. All Users

The All Sessions for User report (see Figure 3, All Sessions for User ) shows selected detail for all the sessions covered by the accounting log file. The date shown is the date and time that the session ended. The sessions are listed in the order they occur in the accounting log file (i.e. by the time the session ended).

FIGURE 3. All Sessions for User

The All Records for Session report (see Figure 4, All Records for Session ) shows all the details for all the records for a single session. This format is useful to see in exhaustive detail all the accounting records for a single session.

FIGURE 4. All Records for Session

FIGURE 5. Typical radwho listing

13.1.1 User-Password, Password

A (usually) plaintext password. Passes only if the given password matches that sent in the Access-Request. If CHAP-Password attribute appears in the request then CHAP authentication will be attempted. CHAP authentication is only supported with plaintext passwords. You may user either Password or User-Password as the attribute name. The effect is the same

User-Password can be in a number of formats, not necessarily in plaintext. Radiator looks for some special format passwords and interprets them as special encryptions. The following formats are supported, along with example versions of the password "fred"

• Standard Unix crypt.This format is also compatible with Unix password encryption as used in Netscape LDAP server. Passwords starting with a leading "{crypt}" are interpreted as a standard Unix crypt password.

 
User-Password = {crypt}1xMKc0GIVUNbE

• Linux MD5 password encryption. Passwords starting with "$1" are interpreted as encrypted with Linux MD5 password encryption.

 
	User-Password = $1$cTpht$Obu9PLSMst1TDou.mN5bk0

• Netscape SHA password encryption as used in Netscape LDAP server. Passwords starting with "SHA" or "SSHA" are interpreted as being encrypted with Netscape SHA encryption. (Requires Perl SHA-1.2.tar.gz module or later).

 
User-Password = {SHA}0DPiKuNIrrVmD8IUCuw1hQxNqZc=

• Plaintext. Any other format is interpreted as a plain text password.

 
User-Password = fred

13.1.2 Encrypted-Password

A crypt(3) encrypted password. Passes only if the password sent in the Access-Request matches the given encrypted password. CHAP authentication cannot be performed with an Encrypted-Password check item.

 
Encrypted-Password = 1xMKc0GIVUNbE

13.1.3 Realm

Checks that the realm in the login name matches. The realm is the part following the @ in the user name. You can use either exact match, or a regular expression.

 
Realm = open.com.au

13.1.4 Expiration

A date in the form Dec 08 1998. Passes only if the current date is prior to the given date.

 
Expiration = Jan 02 1999

13.1.5 Auth-Type

Auth-Type triggers special behaviour for authenticating the user. The possible values are:

• Reject. Any access request will always be rejected. This is useful for temporarily disabling logins for a given user.
• Reject:message. Same as for Reject, except that the message (which can be any string) will be sent back to the user in a Reply-Message. This is useful for telling a user why their login has been rejected.
• Ignore. Any access request will always be ignored (i.e. no reply will be sent back to the NAS). This is sometimes useful for triggering special behaviour in cascaded AuthBy clauses.
• Anything else. Any other word specifies an Identifier in an AuthBy clause which will used to authenticate the user. The name is matched with the name specified in the Identifier parameter in an AuthBy clause. You can name any other type of AuthBy module, be it SQL, RADIUS, UNIX etc. Specifying Auth-Type for a user causes the authentication to be cascaded to another authentication module. You can cascade authentications like this to any arbitrary depth.

The Auth-Type check item is most useful when you want to have check items and/or reply items, but also want to authenticate with native Unix or NT passwords.

Checks all users using the authentication method that has the identifier "System"

 
DEFAULT Auth-Type = System

If you want to temporarily disable logins for a single user:

 
username Auth-Type = Reject

This one rejects the user and tells them why:

 
username Auth-Type = "Reject:you did not pay your bill"

This will first authenticate with the Identifier System, and if they are also in the group "staticip", they will continue to be authenticated with the AuthBy clause that has the Identifier "statics".

 
DEFAULT Auth-Type=System, Group=staticip, Auth-Type=statics

13.1.6 Group

The meaning of Group depends on the type of module that is doing the authentication: For UNIX, it means whether the user is a member of the group as defined by the /etc/group file. For NT, it means whether the user is a member the Local Group on the host where Radiator is running. For other AuthBy modules, it has no meaning, and will always cause a rejection.

 
Group = wheel

13.1.7 Block-Logon-From

Specifies a time in the format 9:00 am or 15:22. Attempts to authenticate after this time of day will fail. If Block-Logon-To is also specified for a later time of day, access is blocked between those times. The time of day that is used is the local time on the host where Radiator is running. Block-Logon-From is superseded by the Time check item (see Section 13.1.11 ) and will not be supported in the future.

13.1.8 Block-Logon-To

Specifies a time in the format 9:00 am or 15:22. Attempts to authenticate before this time of day will fail. If Block-Logon-From is also specified for an earlier time of day, access is blocked between those times. The time of day that is used is the local time on the host where Radiator is running. Block-Logon-From is superseded by the Time check item (see Section 13.1.11 ) and will not be supported in the future.

 
Block-Logon-From = 9:00 am,
Block-Logon-To = 5.00 pm

13.1.9 Prefix

This check item checks for the presence of a certain prefix in the user name. If it is not present the check item will fail. If it is present, it will be removed from the user name and accepted. This is most useful in DEFAULT items to handle different variations of the same users name, but with different reply attributes.

In this example, there might be a user "mikem" in the System authentication method. These user entries will allow Pmikem to log in as a PPP user, and Smikem to login as a Slip user:

 
DEFAULT 			Prefix = P, Auth-Type = System
	Service-Type = Framed-User,
	Framed-Protocol = PPP,
	Framed-IP-Address = 255.255.255.254,
	Framed-MTU = 1500
DEFAULT			Prefix = S, Auth-Type = System
	Service-Type = Framed-User,
	Framed-Protocol = SLIP,
	Framed-IP-Address = 255.255.255.254,
	Framed-Compression = None

13.1.10 Suffix

This check item is very similar to Prefix above, but checks for the presence of a certain suffix in the user name. If it is not present the check item will fail. If it is present, it will be removed from the user name and accepted. This is most useful in DEFAULT items to handle different variations of the same users name, but with different reply attributes.

In this example, there might be a user "mikem" in the System authentication method. These user entries will allow mikem.ppp to log in as a PPP user, and mikem.slip to login as a Slip user:

 
DEFAULT 			Suffix = .ppp, Auth-Type = System
	Service-Type = Framed-User,
	Framed-Protocol = PPP,
	Framed-IP-Address = 255.255.255.254,
	Framed-MTU = 1500
DEFAULT			Suffix = .slip, Auth-Type = System
	Service-Type = Framed-User,
	Framed-Protocol = SLIP,
	Framed-IP-Address = 255.255.255.254,
	Framed-Compression = None

13.1.11 Time

This check item allows you to specify which times of day and which days of the week the user is allowed to log on. The Time check is preferred to the Block-Logon-From and Block-Logon-To check items, which will not be supported in the future.

The format consists of day specifiers followed by hours intervals. Multiple day specifications are permitted with multiple values separated by commas (if you use commas, the entire check item must be enclosed with double quotes ("). Authentication will be permitted if the current local time on the Radiator server is within at least one of the time intervals specified.

Day specifiers are Mo, Tu, We, Th, Fr, Sa, Su for the days of the week. Wk means Mo-Fr and Al means any day. Hours intervals are specified as HHMM-HHMM. Typical examples are:

 
Time = "MoTuWe0800-1400,Wk2200-0400" 
Time = "Al1800-0600,Wk1000-1330"

13.1.12 Simultaneous-Use

Specifies the maximum number of simultaneous sessions permitted for this user. Radiator keeps track of the number of current sessions for a user by counting the Accounting Start and Stop requests received for that user. The value of this check item is either an integer or the name of a file that contains an integer. You can use any of the special formatting characters in the file name. The file will be reread for each authentication: it is not cached, so using a file name can have a slight impact om performance.

Hint: you can set the maximum number of session for all the users in a realm by using the Realm MaxSessions parameter.

 
Simultaneous-Use = 1

13.1.13 Connect-Rate

Specifies the maximum connection speed that this user is permitted to use. Uses the Connect-Info attribute in the request to determine the speed the user is requesting. Note: not all NASs send Connect-Info in Access Requests. Check with your NAS vendor's documentation.

 
Connect-Rate = 28800

13.1.14 NAS-Address-Port-List

Specifies the name of a file that contains a list of permitted NAS address/port combinations. See Section 15.7 for the Portlist file format. The filename can contain any of the special file name characters. The contents of the file are read at most once, and the port list is cached inside Radiator. If the user is not attempting to log in on one of the permitted address/port combinations, they will be rejected.

 
NAS-Address-Port-List %D/portlist

Hint: You can limit users to a particular NAS, irrespective of the port by using the NAS-IP-Address check item, possibly with a regular expression.

Hint: You can limit users to a particular port or set of ports on all NASs by using the NAS-Port check item, possibly with a regular expression.

13.1.15 Any other attribute defined in your dictionary

Checking of all other attributes passes only if the corresponding attribute exists in the request and matches the value specified for the check item.

Radiator allows check items to be specified either as an exact match or as a Perl regular expression (regexp). Radiator regards check items whose value is surrounded with slashes (`/') as a regular expression. Anything else is regarded as an exact match.

• Exact match

The check item will pass only if there is an exact match. The comparison is case sensitive. Radiator will look for an exact match if the value to be matched is not surrounded by slashes.

 
NAS-IP-Address = 203.63.200.5
Caller-Id = 121284

• Perl Regular expression

If the check item is surrounded by slashes (`/'), it is regarded as a Perl regular expression, and Perl is used to test whether the value of the attribute in the request matches the regexp. The expression modifiers `i' and `x' are also permitted.

Perl regular expressions give you an enormous amount of power to control the conditions under which a user can log in. The first example below only matches if the user logs in from the phone numbers 95980981, 95980982, 95980983 or 95980984. The second example only matches of they log into a port number with one digit (i.e. ports 1-9).

 
Caller-Id = /9598098(1|2|3|4)/
NAS-Port = /^\d$/

Hint: Perl regexps are very powerful, but they also take some getting used to. You should use them carefully, and test to make sure they really do what you want. Consult some Perl manuals or a Perl guru for tips on writing regexps.

Hint: You can use the `i' and `x' pattern modifiers to get case-insensitive or extended expressions like this, to match a Class attribute set to "myclass" without regard to case.

 
Class = /myclass/i

Hint: You can set up "negative" matches (ie that only match of the check it is not equal to some string) by using Perl negative lookahead assertions in a regexp. For example, this check item will match all Service-Types except for Framed-User:

 
Service-Type = /^(?!Framed-User)/

13.2.1 Framed-Group

The reply attribute is used in conjunction with FramedGroupBaseAddress in order to allocate an IP address for the user and return it in a Framed-IP-Address attribute. See Section 6.4.7 for more details

 
Framed-Group = 1

13.2.2 Ascend-Send-Secret

Causes the value to be encrypted with the Client's shared secret and returned to the Client.

 
Ascend-Send-Secret = mysecret

13.2.3 Tunnel-Password

Causes the password to be encrypted with the Client's shared secret according to draft-ietf-radius-tunnel-auth-06.txt. The Tunnel-Password tag is set to 0. This is used by Ascend and other NASs for managing VPN tunnels.

 
Tunnel-Password = yourtunnelpassword

13.2.4 Fall-Through

This attribute is not actually returned to the NAS. Its presence causes Radiator to continue looking for a match with the next DEFAULT user name.

 
Fall-Through = yes

13.2.5 Any other attribute defined in your dictionary

Any other attribute will be returned to the client in the reply message. All attributes must be defined in your dictionary.

 
Framed-Protocol = PPP,
Framed-IP-Netmask = 255.255.255.0,
Framed-Routing = None,	Framed-MTU = 1500,	
Framed-Compression = Van-Jacobson-TCP-IP

15.1.1 ATTRIBUTE

This defines the name, Radius attribute number and type for an attribute.

 
ATTRIBUTE Service-Type 6 integer

ATTRIBUTE is the keyword that says this is an attribute definition. Service-Type is the name of the attribute: the string that will be used as the attribute name when printing the attribute and when setting attributes in the user database. 6 is the standard Radius attribute number for the attribute (see RFP 2138), and integer is the data type for this attribute. The supported data types are when you assign values to attributes in the user database are:

• string An ASCII string of up to 253 bytes. trailing NULs will be stripped
• integer A decimal integer.
• date A date as an integer number of seconds since 00:00:00 UTC Jan 1 1970.
• ipaddr An IP address in the form aaa.bbb.ccc.ddd .
• binary Binary data
• abinary An Ascend filter, using the special Ascend filer definition syntax
• data Binary data

If you redefine an ATTRIBUTE by defining a new name for an previously defined attribute number, the new definition will silently replace the old one.

15.1.2 VALUE

This defines a symbolic name for an integer type attribute. When setting the value of an integer attribute in a check or reply item, you can use the symbolic name instead of the raw integer.

 
VALUE Service-Type Login-User		 1

VALUE is a keyword that says this is a value definition. Service-Type means that this is a definition of a value for the Service-Type attribute (which should be of type integer). Login-User is the symbolic name for the value, and 1 is the value that Login-User translates to.

If you redefine a VALUE by defining a new name for a previously defined value number, the new definition will silently replace the old one.

15.1.3 VENDORATTR

This defines a vendor-specific attribute. Radius defines a special attribute number 26 that can be used to hold any vendor defined data type. This allows NAS vendors to add their own NAS-specific codes.

 
VENDORATTR 9 cisco-avpair 1 string

VENDORATTR is a keyword that says this is a vendor-specific attribute definition. 9 is the SMI Network Management Private Enterprise Code of the vendor (Cisco in this example). cisco-avpair is the symbolic name for the attribute, and string is the data type. The same data types as for ATTRIBUTE are supported. Radiator supports both hex and decimal attribute numbers in VENDORATTR.

After an integer VENDORATTR is defined, you can have VALUE definitions in the same format as for other ATTRIBUTES.

If you redefine a VENDORATTR by defining a new name for an previously defined vendor attribute number, the new definition will silently replace the old one.

15.1.4 Available dictionaries

Radiator comes with a number of dictionaries:

• dictionary . The is the normal and default one. It merges attribute definitions from several sources, and should be satisfactory for most users.
• dictionary.ascend . This is the standard Ascend dictionary, which you should use if you are using Ascends.
• dictionary.ascend2 . This is a dictionary for recent model Ascends. Ascend have recently stopped using commandeered standard Radius attributes for their own use, and are now using Vendor-Specific attributes. Use this dictionary if you get error messages from Radiator like:

 
 Mon Mar 22 23:28:02 1999: ERR: Attribute number 125 
      (vendor 529) is not defined in your dictionary

(Vendor 529 is Ascend)

• dictionary.cisco . This is a standard Cisco dictionary. You should never need to use this, as all its values are in dictionary , but its there in case you want to use it.
• dictionary.livingston . This is the standard Livingston dictionary. You should never need to use this, as all its values are in dictionary, but its there in case you want to use it.
• dictionary.usr . This is a modified USR/3COM dictionary suitable for use with USR NASs (USR has been taken over by 3COM).

You should be very careful if you select the Cisco or Ascend dictionaries, as they both define unusual names for the values of the Service-Type attribute (amongst others). The names they use are inconsistent with the names in the example users file and the defaults for radpwtst . On balance, you might be better off using the standard dictionary. If you really want to use those dictionaries, you must be sure that your user database and options for radpwtst are using the value names from the dictionary you choose. Failure to do this can cause difficult to find authentication failures.

Your dictionary must have entries for at least the following attributes, which are referred to by name in the radiusd code.

• User-Name
• User-Password
• Encrypted-Password
• Acct-Delay-Time
• Any other attributes that are required by your AuthBy SQL configuration (if any) or the check and reply items your user database.

Choosing which dictionary to use takes some thought. Here are some guidelines. Wherever possible, use the generic dictionary: it will work with the vast majority of cases.If you are operating with NASs from only one vendor, choose the standard dictionary, or dictionary for that vendor. If you are operating in a mixed environment, use the default dictionary. If that does not work for you, try concatenating the dictionaries for the vendors you are using into one big dictionary. You are of course free to modify any of the dictionaries to add attributes or values that are missing for your particular NAS.

Whichever dictionary you choose to use, you should place it in the directory where radiusd expects to find it before starting radiusd . You should also be careful to specify the same dictionary to radpwtst with the -dictionary argument if you use it for testing.

FIGURE 6. Typical user entry in a flat file user database

FIGURE 7. Typical accounting log file entry

FIGURE 8. Radiator Class inheritance hierarchy

FIGURE 9. Schematic diagram of how iPASS outbound requests are handled

In order to configure Radiator to handle outbound iPASS requests, you need to do the following things:

1. Enter into a commercial arrangement for iPASS to provide Net Server access to you. iPASS will provide you with an ISP partner number.
2. Request the iPASS library package for your platform from iPASS. This package will usually include the VNAS software required for inbound operation too. This is not the normal package provided to iPASS customers. The normal package does not include the iPASS libraries. You must make a special request to iPASS for them.
3. Install and configure the library package according the instructions included with it. This will involve configuring the package, requesting and receiving an encryption certificate, and submitting details of your server and realm to iPASS. Install the package in the normal place (/usr/ipass).
4. Test the installed package by using the test programs provided with it. Make sure it is really working properly before you go on to the next step.
5. Acquire the IpassPerl module from Open System Consultants. This module allows Radiator to use the iPASS library package.
6. Install IpassPerl by following the instructions included with it in the README file.
7. Configure Radiator by adding a default Realm (to handle all non-local realms), with an authentication method of IPASS, for example:

 
<Realm DEFAULT>
  <AuthBy IPASS>
  </AuthBy>
</Realm>

1. Test Radiator with the radpwtst program to make sure that requests for non-local realms are forwarded to iPASS.

Hint: If it doesn't seem to be working, add the Debug parameter to AuthBy IPASS and look in the iPASS trace file (usually /usr/ipass/logs/iprd.trace ).

Hint: You may need to run Radiator as root on Unix, as the iPASS encryption certificate may be installed read-only by root.

FIGURE 10. Schematic diagram of how iPASS inbound requests are handled

In order to configure Radiator to handle inbound iPASS requests, you need to do the following things:

1. Enter into a commercial arrangement for iPASS to provide Roam Server access to you. iPASS will provide you with an ISP partner number.
2. Request the iPASS VNAS software for your platform from iPASS.
3. Install and configure the VNAS software according to the instructions included with it. This will involve configuring the package, requesting and receiving an encryption certificate, and submitting details of your sever and realm to iPASS. Install the package in the normal place (/usr/ipass). If you have already done this for outbound requests above, you don't need to do it again.
4. Configure Radiator in the usual way for your local realms. Add a Client clause specifying the host where the VNAS software is running, and the shared secret you configured into VNAS:

 
<Client localhost>
  Secret vnassecret
</Client>
<Realm ...>
  ....

1. Test that VNAS sends requests to Radiator by using the test software provided with VNAS.

Hint: VNAS needs a clients file to locate the shared secret for communicating with Radiator. It will ask for the location of the file during VNAS configuration. You should specify something like /usr/ipass/raddb/clients .

23.6.1 Cisco

There is a Net News group for cisco: comp.dcom.sys.cisco.

23.6.2 Ascend

There are two mailing lists for Ascend users. You can subscribe to either list, or a digest version of the list. The digest version accumulates all messages received during the day into one (or more) messages sent out each evening.

To subscribe to the main list, send a message with the words

 
subscribe ascend-users

in the body of the message (not the subject) to ascend-users-request@bungi.com.

To subscribe to the digest version of the list send a message with the word

 
subscribe

in the body of the message (not the subject) to ascend-users-digest-request@bungi.com

The submission address to send entries to the list is: ascend-users@bungi.com.

Ascend maintain a web site with FAQs and product details at

 
http://www.ascend.com
.

23.6.3 Livingston Mailing Lists

Livingston kindly host a number of mailing lists for different groups interested in Livingston products and Radius in general. More detail on Livingston products and searchable mailing list archives can be found at

 
http://www.livingston.com
.

To subscribe to a Livingston mailing list, email majordomo@livingston.com with

 
subscribe list-name

in the body of your letter, where list-name is one of the following:

• portmaster-announce

Announcements from Livingston.

• portmaster-users

General discussion group, will also have all traffic from -announce.

• portmaster-users-digest

A digested version of the -users group.

• portmaster-radius

A discussion group for Radius developers working with Livingston equipment.

• portmaster-radius-digest

A digested version of the -radius group

To unsubscribe, email the same address with

 
unsubscribe list-name