Index for Section 5

Alphabetical listing for D

Bottom of page

DICTIONARY(5)
NAME
  dictionary - dictionary translations for parsing RADIUS requests

SYNOPSIS
  ../raddb/dictionary

DESCRIPTION
  The dictionary file resides in the Interlink AAA Server configuration
  directory (named .../raddb somewhere).  It contains a list of dictionary
  translations which the Interlink AAA Server will use to parse incoming
  requests and to generate outgoing responses.	Comments are indicated by
  leading pound sign ('#') characters.	All such comment lines are ignored
  (as are blank lines).

  All transactions are composed of Attribute/Value Pairs.  The value of each
  attribute is specified as one of several data <type>s.

  Valid <type>s include:

  string    - 0-253 octets
  octets    - 0-253 undistinguished octets (experimental, for display only)
  vendor    - first octet is zero, then three octets IANA #, then the rest
  tag-int   - single octet followed by three octets of integer value
  tag-str   - single octet followed by 0-252 octets
  abinary   - 0-254 Ascend binary filter octets
  ipaddr    - 4 octets in network byte order
  integer   - 32 bit integer value in big endian order (high byte first)
  octet	    - 8 bit integer value
  short	    - 16 bit integer value in big endian order (high byte first)
  date	    - 32 bit value in big endian order - seconds since 00:00:00 GMT,  Jan.  1,	1970

  The ATTRIBUTE entries consist of four required fields and one optional
  fifth field:

	      ATTRIBUTE	   <attribute-name>    <integer-encoding>    <type>
       [<pruning>]

  The VALUE entries consist of four fields:

	      VALUE	    <attribute-name>	 <value-name>
       <integer-encoding>

  For example:

       ATTRIBUTE       Framed-Protocol	       7       integer	(1,0)

  and

       VALUE		 Framed-Protocol	 PPP	1

  The optional <pruning> field on attribute lines controls the following
  features of the Interlink AAA Server:

       ·	 whether the attribute is ever sent to the NAS

       ·	 how the NAS reacts to a reply which contains the attribute

       ·	 other features such as logging and encapsulation

  The syntax of the <pruning> expressions is as folows:

  [ ( [<ack>] [ [ [,] [<nak>] ] [ [,] [<chal>] ] [ [,] [ MAY | MUST | CONFIG
  | NOLOG | [NO] ENCAPS ] ] ] ) ]
      \____first pruning feature above____/	 \____other pruning features above____/

  In the first pruning feature flags above, <ack>, <nak> and <chal> are one
  of '0', '1' or '*'.  The <ack>, <nak> and <chal> values affect Access-
  Accept, Access-Reject and Access-Challenge replies, respectively.  These
  values represent:

       0	 no attributes of this kind are part of the final reply
		 (DEFAULT)

       1	 at most, one attribute of this kind may be part of the final
		 reply

       *	 any number of attributes of this kind may be part of the
		 final reply

  The default values for <ack>, <nak> and <chal> are zero!  Keep this in mind
  when adding vendor specific attributes since they will not be returned to
  the NAS in any replies unless this expression exists.	 Interlink is not
  responsible for the correct interpretation of these flags for all of the
  vendor specific attributes in the dictionary file.  Final authority for the
  correct setting of these flags rests with each specific vendor.  If any
  errors are found, please send corrections to support@interlinknetworks.com,
  and we will try to make the change effective with our next release.

  The remaining keywords define how the NAS reacts to the attribute and how
  the Interlink AAA Server deals with certain attributes:

       MUST	 the NAS must reject the request if it does not recognize
		 this attribute

       MAY	 the NAS may ignore the attribute if not recognized (DEFAULT)

       CONFIG	 the attribute is a configuration item

       NOLOG	 the attribute is not allowed to be logged

       ENCAPS	 the attribute is always encapsulated within the Vendor-
		 Specific attribute (26) regardless of the vendor (DEFAULT)

       NOENCAPS	 the attribute is not encapsulated within the Vendor-Specific
		 attribute (26)

  The CONFIG keyword is only for the internal use of this Interlink AAA
  Server and must be given by itself (i.e., (config) at the end of the
  attribute line).

  If any value is omitted, but the comma is present for that value, then just
  that value takes on the default.  The keywords MAY and MUST only are
  meaningful for RADIUS Version Two (DIAMETER).

  A new syntax for handling vendor specific attributes is supported:

       <vendor>:<attribute-string>

  where <vendor> is the vendor's name and <attribute-string> is a unique
  string (for that vendor).  This syntax may be used here and in the users
  file.	 There is an alternate syntax available for specifying vendor
  specific attributes and values.  Vendor specific attribute and value
  identifier strings may be defined in the vendors file which may be used in
  place of the default strings ATTRIBUTE and VALUE.

  The dictionary file is read by radiusd at startup only.  Changing the
  dictionary file is something which should only be undertaken with great
  care and only if the changer completely understands the proposed change and
  its effects.

FILES
  ../raddb/dictionary

SEE ALSO
  signal(3), users(5), vendors(5), radiusd(8), radcheck(8), radpwtst(8)

Index for Section 5

Alphabetical listing for D

Top of page