CLIENTS(5)CLIENTS(5)NAMEclients - RADIUS client/host to shared-secret mapping file
SYNOPSIS
../raddb/clients
DESCRIPTION
The clients file resides in the Merit AAA server configu-
ration directory (named .../raddb somewhere). It contains
a list of clients and servers (or pairs of same). Com-
ments are indicated by leading pound sign ('#') charac-
ters. 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:
merit.edu notsosecure type = nas v2 pfx
The <system-name> field may be an IP address (in dotted-
quad notation) or a valid Domain Name System (DNS) host-
name. This optionally may be followed by a colon (":")
and a UDP/TCP port number. This value overrides the -pp
and -qq options of the Merit 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:
name1/name2
This allows the same clients file to be used by and dis-
tributed to physically different, but like configured,
Merit AAA servers. A RADIUS request from a client or
server will match such an entry only if its source IP
address matches the IP address of name1 or name2 and name2
or name1 matches the host name of this server as returned
by the hostname(1) command. Using this style for the
first field precludes the use of the optional [:port] mod-
ifier.
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 six-
teen character maximum no longer applies to version 3.x
5 December 1997 1
CLIENTS(5)CLIENTS(5)
Merit 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 Merit
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 Merit 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 con-
forming 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 debug-
ging is enabled), APPEND indicates this client is not a
modern Merit AAA Server with respect returning RADIUS rep-
plies, OLDCHAP indicates this client handles CHAP requests
in the older, pre-RFC fashion and NOENCAPS indicates that
no encapsulation of vendor specific attributes is neces-
sary for this client. These various types may be logi-
cally combined ("ANDed") using the plus sign ("+") charac-
ter. 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 docu-
ment, and version two is described in draft-calhoun-enh-
radius-00.txt written by Pat Calhoun of US Robotics. Cur-
rently, the following values are recognized for the ver-
sion field: V1 and V2.
The optional <prefix> field specifies a text string prefix
5 December 1997 2
CLIENTS(5)CLIENTS(5)
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 Merit AAA server, but use different authentica-
tion 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
Merit 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 ALSOhostname(1), signal(3), authfile(5), dictionary(5),
users(5), vendors(5), radiusd(8), radcheck(8), radpwtst(8)
5 December 1997 3