 |
» |
|
|
 |
The dictionary file lists dictionary translations that the server uses
to parse incoming requests and generate outgoing responses. All transactions
are composed of Attribute-Value (A-V) pairs. See Chapter 24 “Attribute-Value Pairs” for information about the
data format of A-V pairs in RADIUS messages.  |  |  |  |  | IMPORTANT: Configuration files have a maximum input line length
of 255 characters. No checking is done to insure that a configuration
statement has not exceeded this limit. All configuration files must
end with a new line. |  |  |  |  |
You can track different versions of the dictionary file by
adding the following line to the file: - Version-String
is the version information.
This string will appear in radcheck output.
Attribute
Entries |  |
Below is the syntax of Dictionary Attribute entries: ATTRIBUTE attribute-name integer-encoding type pruning |
 |  |  |  |  | NOTE: Vendor-specific attribute identifier strings
are defined in the vendors file and can be used in place of the default string ATTRIBUTE. For more information, see “Syntax
of a vendors File”. |  |  |  |  |
- attribute-name
Replaced with the unique
name of an attribute. - integer-encoding
Replaced with the actual
attribute number code used in the A-V pair data format. - type
Replaced with one of the
following data types for the attribute: octet:
8-bit unsigned integer value short: 16-bit unsigned
integer value integer: 32 bit 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) octets: 0-253 undistinguished octets a binary: 0-253
Ascend binary filter octets vendor: 0-253 octets
with octets 0-3 representing the IANA number ipaddr: 4 octets in network
byte order ipv6addr: 16 octets in network byte
order (used for IPv6 attributes) ipv6prefix: 4-20 octets (used
for IPv6 attributes) ifid: 8 undistinguished octets (used
for IPv6 attributes) tag-int: single
octet followed by three octets of integer value (used for tunneling
attribute) tag-string: single
octet followed by 0-252 octets (used for tunneling attribute)
- pruning
May be replaced with an optional expression
that controls three server features whether
the attribute is ever sent to the NAS whether or not the attribute
may be logged encapsulation, if used, for vendor-specific
attributes
Pruning
Expressions |  |
Pruning is a feature that allows the server to remove A-V
pairs from an Access-Accept, Access-Reject, or
Access-Challenge message before sending the message to
a client that has been configured for pruning in the clients file,
see “The clients File”. The pruning
to apply is defined by pruning expressions in the dictionary's attribute
entries. These optional expressions are defined in an attribute entry
as follows: (ack, nak, chall, {NOLOG | ENCAPS | NOENCAPS}) |
 |  |  |  |  | NOTE: If any value is omitted, but the comma is present for
that value, that value will use its default. If the expression is
omitted, all values use their defaults. |  |  |  |  |
- ack, nak, chall,
determine how many instances
of the attribute may be added to an Access-Accept (ack),
an Access-Reject (nak), or an Access-Challenge
(chall) reply. They can be specified as one of the following values:
0: no attributes
of this kind are part of the final reply. This is the default value. 1: at most, one attribute
of this kind can be part of the final reply. *: any number of attributes
of this kind can be part of the final reply.
 |  |  |  |  | NOTE: Since the default values for ack, nak, and chall are 0, added vendor-specific
attributes will not be returned to the NAS in any replies if you
do not include a pruning expression. |  |  |  |  |
- {NOLOG | ENCAPS | NOENCAPS}
define how the server reacts
to the attribute:
NOLOG: the attribute will not be added to the logfile
or session logs. ENCAPS (or ENCAPSULATE): the attribute will be encapsulated in the vendor-specific
attribute, regardless of the vendor. This is a default value. NOENCAPS: the attribute will not be encapsulated within
the vendor-specific attribute.
 |  |  |  |  | NOTE: ENCAPS and NOENCAPS keywords are mutually exclusive. If you specify both,
only the last one will apply. |  |  |  |  |
Examples ATTRIBUTE Framed-Protocol 7 integer (1, 0, 0) ATTRIBUTE User-Realm 223 string (*, 0, 0, NOENCAPS) |
|