4.2 Dictionary of Attributes — ‘raddb/dictionary’

The dictionary file ‘raddb/dictionary’ defines the symbolic names for radius attributes and their values (see section Attributes). The file consists of a series of statements, each statement occupies one line.

In the detailed discussion below we use the following meta-syntactic characters:

number

Denotes a decimal, octal or hexagesimal number. Usual C conventions are honored, i.e. if number starts with ‘0x’ or ‘0X’ it is read as a hex number, if it starts with ‘0’ it is read as an octal number, otherwise it is read as a decimal one.

type

Denotes an attribute type. These are valid attribute types:

string

A string type.

integer

An integer type.

ipaddr

IP address in a dotted-quad form.

date

A date in the format: "MON DD CCYY", where MON is the usual three-character abbreviation, DD is day of month (1-31), CCYY is the year, including the century.

4.2.1 Comments

Comments are introduced by a pound sign (‘#’). Everything starting from the first occurrence of ‘#’ up to the end of line is ignored.

4.2.2 $INCLUDE Statement

Syntax

$INCLUDE ‘filename’

Usage

The $INCLUDE statement causes the contents of the file ‘filename’ to be read in and processed. The file is looked up in the Radius database directory, unless its name starts with a slash.

4.2.3 VENDOR Statement

Syntax

VENDOR  vendor-name vendor-id

Usage

A VENDOR statement defines the symbolic name vendor-name for vendor identifier vendor-id. This name can subsequently be used in ATTRIBUTE statements to define Vendor-Specific attribute translations. See section Vendor-Specific.

Example

VENDOR  Livingston  307

4.2.4 ATTRIBUTE statement

Syntax

ATTRIBUTE  name  number  type [vendor] [flags]

Usage

The ATTRIBUTE statement defines the internal representation of an attribute: its symbolic name, data type and syntactical usage. Its parts have the following meaning:

name

The attribute name.

number

The attribute ID (number).

type

The attribute type.

vendor

Vendor name for vendor-specific attributes. For usual attributes this field is empty or contains a dash (‘-’). The latter usage is for compatibility with previos version of GNU Radius

flags

Flags, defining attribute properties (see section Attributes).

The attribute property flags consist of a sequence of letters, whose meaning is determined by the following rules: (2)

1. The attribute usage is described by three pairs of symbols, enclosed in square brackets. Each pair describes how the attribute can be used in each of three configuration files. The first pair corresponds to ‘raddb/users’, the second one corresponds to ‘raddb/hints’, and the third one corresponds to ‘raddb/huntgroups’. Within each pair, the letter ‘L’ in first position means that the attribute is allowed in LHS of a rule. The letter ‘R’ in second position means that the attribute is allowed in RHS of a rule. The absence of any of these letters is indicated by dash (‘-’). Thus, the following usage specification:

   [L--RLR]

   means that the attribute may be used in LHS of a rule in ‘raddb/users’, in RHS of a rule in ‘raddb/hints’, and in both sides of a rule in ‘raddb/huntgroups’.

2. The attribute additivity is described by one of the following letters:

   =

   Additivity = Replace

   +

   Additivity = Append

   N

   Additivity = None

3. The presence of letter ‘P’ in property flags raises the propagation bit.
4. Letter ‘l’ (lower-case ell) enables logging the given attribute in detail file (see section Detailed Request Accounting). This is meaningful only for internal attributes, i.e. the ones whose decimal value is greater than 255 (see section Radius Internal Attributes). By default such attributes do not appear in detailed logs. The flag ‘l’ reverts this behavior.
5. Letter ‘E’ marks attributes encrypted as described in RFC 2138. Currently these are User-Password and CHAP-Password.
6. Letter ‘T’ marks attribute encrypted according to RFC 2868.
7. The characters from ‘1’ to ‘9’ denote nine user-defined flags (see section Extended Comparison).

Example

ATTRIBUTE  Service-Type  6 integer - [LR-RLR]=P 

This statement declares that the attribute number 6 will be referred to by the symbolic name ‘Service-Type’. The attribute is of integer data type and it may be used in any part of matching rules, except in LHS of a ‘raddb/hints’ rule. The additivity of Service-Type is set to ‘Replace’. The attribute will be propagated through the proxy chain.

4.2.5 Blocks of Vendor-Specific Attributes

Syntax

BEGIN VENDOR vendor-name [vendor-id]
…
END 

Usage

The BEGIN keyword marks start of the block of definitions of vendor-specific attributes. The block is terminated by END keyword, optionally followed by an arbitrary number of words, which are regarded as a comment. The block may contain any valid dictionary declarations, except other blocks: nesting of declaration blocks is not allowed.

If vendor-id is absent, the value of vendor ID is looked up in the internal table of vendors; therefore, it must be defined before BEGIN statement (see section VENDOR Statement).

BEGIN---END block alters the handling of ATTRIBUTE statements within it. If ATTRIBUTE statement does not contain an explicit vendor-id specification, the value of vendor-id is used instead.

For compatibility with FreeRadius an alternative syntax is also supported:

BEGIN-VENDOR vendor-name
…
END-VENDOR vendor-name

Such compatibility blocks must appear only ater the declaration of vendor-name (see section VENDOR Statement).

Example

The following is the usual way of definig vendor-specific attributes:

VENDOR          Livingston      307

ATTRIBUTE       LE-Terminate-Detail     2       string  Livingston
ATTRIBUTE       LE-Advice-of-Charge     3       string  Livingston

The following two examples show the alternative ways:

VENDOR Livingston 307
BEGIN VENDOR Livingston
ATTRIBUTE       LE-Terminate-Detail     2       string  
ATTRIBUTE       LE-Advice-of-Charge     3       string
END

BEGIN VENDOR Livingston 307
ATTRIBUTE       LE-Terminate-Detail     2       string  
ATTRIBUTE       LE-Advice-of-Charge     3       string
END

These three examples are completely equivalent to each other.

4.2.6 ALIAS statement

Syntax

ALIAS name  alt-name

Usage

The ALIAS statement defines an altenative name alt-name for attribute name. The latter should already be defined, otherwise an error occurs.

Example

ALIAS User-Password Password

4.2.7 PROPERTY statement

Syntax

PROPERTY  name  flags
PROPERTY  name  +flags [-flags ...]

Usage

The PROPERTY statement redefines property flags for attribute name. The attribute must be defined, otherwise an error occurs. The PROPERTY statement has two forms. In first form, it takes a single argument, representing new property flags for the attribute. In its second form it takes any number of arguments, each of them preceeded by ‘+’ sign, inidicating addition of properties, or by ‘-’ sign, indicating removal of these.

See section ATTRIBUTE statement, for the discussion of attribute property flags.

Example

The following example defines that the attribute User-Password may be used only on left-hand side of a ‘raddb/users’ entry, and that it is transmitted in encrypted form.

PROPERTY  User-Password [L-----]E

Next example illustrates adding and removing attribute properties:

PROPERTY  My-Attrib     +P -=

it adds propagation bit (‘P’) and removes ‘replace’ additivity from My-Attrib attribute.

4.2.8 VALUE Statement

Syntax

VALUE   Attribute-Translation       Value-Translation       number

Usage

The VALUE statement assigns a translation string to a given value of an integer attribute. Attribute-Translation specifies the attribute and the Value-Translation specifies the name assigned to the value number of this attribute.

Example

The following assigns the translation string ‘Login-User’ to the value 1 of the attribute ‘Service-Type’.

VALUE  Service-Type  Login-User  1

This document was generated by Sergey Poznyakoff on December, 6 2008 using texi2html 1.78.