clients man page on BSDOS

Man page or keyword search:  
man Server   6284 pages
apropos Keyword Search (all sections)
Output format
BSDOS logo
[printable version]



CLIENTS(5)					       CLIENTS(5)

NAME
       clients - 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 ALSO
       hostname(1),   signal(3),   authfile(5),	   dictionary(5),
       users(5), vendors(5), radiusd(8), radcheck(8), radpwtst(8)

			 5 December 1997			3

[top]
                             _         _         _ 
                            | |       | |       | |     
                            | |       | |       | |     
                         __ | | __ __ | | __ __ | | __  
                         \ \| |/ / \ \| |/ / \ \| |/ /  
                          \ \ / /   \ \ / /   \ \ / /   
                           \   /     \   /     \   /    
                            \_/       \_/       \_/ 
More information is available in HTML format for server BSDOS

List of man pages available for BSDOS

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net