Synopsis Notes

/usr/local/billmax/radius/raddb/clients

DESCRIPTION

The clients file resides in the Interlink AAA server configuration directory (named .../raddb somewhere). It contains a list of clients and servers (or pairs of same). Comments are indicated by leading pound sign ('#') characters. All such comment lines are ignored (as are blank lines).

The file contains a line of information for each client or server. Each line has up to five, white-space delimited fields. The first two fields are required while the last three fields are optional. Each line has the following of the form: <system-name[:port]> <key> <type> <version> <prefix>

For example:

For example:

The <system-name> field may be an IP address (in dotted-quad notation) or a valid Domain Name System (DNS) hostname. This optionally may be followed by a colon (":") and a UDP/TCP port number. This value overrides the -pp and -qq options of the Interlink AAA server (see the radiusd(8) man page). The accounting UDP port number is assumed to be one greater than the authentication UDP port number. A pair of clients or servers may be specified using the following alternate notation:

The <key> field is the encryption key or "shared secret" held between a RADIUS server and a client or between two RADIUS servers. The secret field may be arbitrarily large, but should be kept to less than several hundred characters for administrative convenience. The older sixteen character maximum no longer applies to version 3.x Interlink AAA Servers.

The <type> field may specify the vendor name and/or the type of the machine exchanging RADIUS requests with this server. The vendor is indicated by placing one (or more) vendor's name(s) in front of the client type and separated with a colon (":") character. If more than one vendor is specified, use the ("+") character to separate them. For example,

type = ascend:nas

There is a default vendor "Merit" which results in Interlink Vendor-Specific attributes being sent off this machine without being encapsulated in the type 26 Vendor-Specific attribute. There is a special vendor "none" which may be used to force these Interlink Vendor-Specific attributes to be encapsulated. This may be used to help prevent inter-operability problems.

The server applies a technique called pruning which is driven by configurable entries in the dictionary file (see the dictionary(5) man page). When an attribute is pruned it is not sent to the client. It makes little sense to send a proprietary attribute defined by vendor A to a RADIUS client manufactured by vendor B.

Currently, the following values are recognized for the type field: NAS, PROXY, RAD_RFC, ACCT_RFC, DEBUG, APPEND, OLDCHAP, NOENCAPS, and for US Robotics products DAS, FRGW, and NEIGHBOR, where RAD_RFC indicates a RADIUS RFC conforming client, ACCT_RFC indicates conformance with the RADIUS accounting RFC, DEBUG tells the server to turn on packet level debugging for just this client (when debugging is enabled), APPEND indicates this client is not a modern Interlink AAA Server with respect returning RADIUS replies, OLDCHAP indicates this client handles CHAP requests in the older, pre-RFC fashion and NOENCAPS indicates that no encapsulation of vendor specific attributes is necessary for this client. These various types may be logically combined ("ANDed") using the plus sign ("+") character. For example,

type = NAS+RAD_RFC+ACCT_RFC

The optional <version> field specifies the RADIUS version number. If this is omitted, it defaults to version one. Version one is described in the IETF RADIUS standard document, and version two is described in draft-calhoun-enh-radius-00.txt written by Pat Calhoun of US Robotics. Currently, the following values are recognized for the version field: V1 and V2.

The optional <prefix> field specifies a text string prefix which may be used to select an authfile and/or users file, which is different than the "standard" authfile or users file, to be used for requests from the associated client. This feature allows for different RADIUS clients to share the same Interlink AAA server, but use different authentication databases on this server. The prefix is pre-pended to the configuration file name (normally, "users" and "authfile").

The clients file information is read by radiusd upon startup, or when a HUP signal is received by radiusd. The Interlink AAA server detects any out-of-date configuration files upon receipt of a Status-Server (or Management-Poll) request and re-reads all the configuration files. This file is maintained by the system administrator using a text editor.

FILES

../raddb/authfile, ../raddb/clients, ../raddb/dictionary, ../raddb/users

SEE ALSO

hostname(1), signal(3), authfile(5), dictionary(5), users(5), vendors(5), radiusd(8), radcheck(8), radpwtst(8)