DICTIONARY(5)DICTIONARY(5)NAMEdictionary - dictionary translations for parsing RADIUS
requests
SYNOPSIS
../raddb/dictionary
DESCRIPTION
The dictionary file resides in the Merit AAA server con-
figuration directory (named .../raddb somewhere). It con-
tains a list of dictionary translations which the Merit
AAA server will use to parse incoming requests and to gen-
erate outgoing responses. Comments are indicated by lead-
ing 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 four
data <type>s.
Valid <types> include:
; l l. string - 0-253 octets vendor - octet #0 is
zero, then three octets IANA #, then the rest octets -
0-253 undistinguished octets abinary - 0-254 Ascend
binary filter octets ipaddr - 4 octets in network byte
order octet - 8 bit integer value short - 16 bit
integer value in big endian order (high byte first)
integer - 32 bit integer value in big endian order (high
byte first) date - 32 bit value in big endian order - sec-
onds 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
two features of the Merit AAA server:
9 December 1997 1
DICTIONARY(5)DICTIONARY(5)
a) whether the attribute is ever sent to the
NAS
b) how the NAS reacts to a reply which con-
tains the attribute
The syntax of the <pruning> expressions is as folows:
[ ( [<ack>] [ [ [,] [<nak>] ] [ [,] [ MAY | MUST |
CONFIG ] ] ] ) ]
\__feature 'a)' above__/ \__feature 'b)' above__/
In 'a)' above, <ack> and <nak> are one of '0', '1' or '*'.
The <ack> and <nak> values affect Access-Accept and
Access-Reject replies, respectively. These values repre-
sent:
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 both <ack> and <nak> are '0'! 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.
In 'b)' above, the keywords define how the NAS reacts to
the attribute:
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
The CONFIG keyword is only for the internal use of this
Merit AAA server and must be given by itself (i.e., (con-
fig) 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 ver-
sion two.
A new syntax for handling vendor specific attributes is
supported:
9 December 1997 2
DICTIONARY(5)DICTIONARY(5)
<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 identi-
fier 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 and
whenever 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/dictionary
SEE ALSOsignal(3), users(5), vendors(5), radiusd(8), radcheck(8),
radpwtst(8)
9 December 1997 3
