Index for Section 5

Alphabetical listing for C

Bottom of page

CLIENTS(5)
NAME
  clients - RADIUS client/host to shared-secret mapping file

SYNOPSIS
  ../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 three fields
  are required while the last two fields are optional.	Each line has the
  following of the form:

       <system-name[:port]>  <key>  <type>  <version>  <prefix>

  For example:

       interlinknetworks.com	  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) 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:

	     name1/name2

  This allows the same clients file to be used by and distributed to
  physically different, but like configured, Interlink 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] modifier.

  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 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.  This
  client is not a proxy but the originating NAS.  The pruning feature only
  occurs on the "last hop" to a NAS unless a PRUNE flag is specified.  If the
  Interlink AAA Server is not adjacent to a NAS then pruning will not occur.
  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, PRUNE, 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 to
  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,
  and PRUNE forces pruning on the next hop.  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 a series of
  IETF drafts written by Pat Calhoun of Sun Microsystems.  Look for the
  keyword DIAMETER in the standard IETF drafts locations.  Currently, the
  following values are recognized for the version field: V1 and V2.  The use
  of the V2 version is NOT recommended at this time.

  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)

Index for Section 5

Alphabetical listing for C

Top of page