1dictionary(5) File Formats Manual dictionary(5)
2
6 dictionary - RADIUS dictionary file
7
9 The master RADIUS dictionary file resides in /etc/raddb/dictionary. It
10 references other dictionary files located in /usr/share/freeradius/.
11 Each dictionary file contains a list of RADIUS attributes and values,
12 which the server uses to map between descriptive names and on-the-wire
13 data. The names have no meaning outside of the RADIUS server itself,
14 and are never exchanged between server and clients.
15 That is, editing the dictionaries will have NO EFFECT on anything other
17 than the server that is reading those files. Adding new attributes to
18 the dictionaries will have NO EFFECT on RADIUS clients, and will not
19 make RADIUS clients magically understand those attributes. The dictio‐
20 naries are solely for local administrator convenience, and are specific
21 to each version of FreeRADIUS.
22 The dictionaries in /usr/share SHOULD NOT be edited unless you know
24 exactly what you are doing. Changing them will most likely break your
25 RADIUS deployment.
26 If you need to add new attributes, please edit the /etc/raddb/dictio‐
28 nary file. It's sole purpose is to contain site-local defintions that
29 are added by the local administrator.
30
33 Every line starting with a hash sign ('#') is treated as comment and
34 ignored.
35 Each line of the file can contain one of the following strings:
37 ATTRIBUTE name oid type [flags]
39 Define a RADIUS attribute name to number mapping.
40 The name field is a printable field, taken from various specifica‐
42 tions or vendor definitions. It is most commonly used as a series
43 of words, separated by hyphens. e.g. "User-Name". Vendor-spe‐
44 cific attributes (VSAs) are prefixed by the vendor name, e.g.
45 "Cisco-AVPair". The names should be globally unique, as they are
46 used as a key to look up the properties of the attribute.
47 The oid field is taken from the relevant specification for that
49 name. In most cases, it is a decimal number, such as "256". For
50 certain attributes, a "dotted number" notation is used, e.g.
51 "1.2". The "dotted number" notation is used only for certain
52 attributes.
53 The type field can be one of the standard types:
55 string UTF-8 printable text (the RFCs call this "text")
57 octets opaque binary data (the RFCs call this "string")
58 ipaddr IPv4 address
59 date Seconds since January 1, 1970 (32-bits)
60 integer 32-bit unsigned integer
61 ipv6addr IPv6 Address
62 ipv6prefix IPV6 prefix, with mask
63 ifid Interface Id (hex:hex:hex:hex)
64 integer64 64-bit unsigned integer
65 The type field can be one of the following non-standard types:
67 ether Ethernet MAC address
69 abinary Ascend binary filter format
70 byte 8-bit unsigned integer
71 short 16-bit unsigned integer
72 signed 31-bit signed integer (packed into 32-bit field)
73 tlv Type-Length-Value (allows nested attributes)
74 ipv4prefix IPv4 Prefix as given in RFC 6572.
75 The last (optional) field of an attribute definition are addi‐
77 tional flags for that attribute, in a comma-separated list. Pre‐
78 vious versions of the server allowed these flags to include a ven‐
79 dor name. This behavior may still work, but it is deprecated, and
80 is not recommended.
81 The options are:
83 encrypt=# set encryption type 1, 2, or 3.
85 has_tag The attribute can have an RFC 2868 style tag
86 The "encrypt" flag marks the attribute as being encrypted with one
88 of three possible methods. "1" means that the attribute is
89 encrypted with the method as defined in RFC2865 for the User-Pass‐
90 word attribute. "2" means that the password is encrypted with the
91 method as defined in RFC2868 for the Tunnel-Password attribute.
92 "3" means that the attribute is encrypted as per Ascend's defini‐
93 tions for the Ascend-Send-Secret attribute.
94 The "has_tag" flag marks the attribute as being permitted to have
96 a tag, as defined in RFC2868. The purpose of the tag is to allow
97 grouping of attributes for tunneled users. See RFC2868 for more
98 details.
99 When the server receives an encoded attribute in a RADIUS packet,
101 it looks up that attribute by number in the dictionary, and uses
102 the definition found there for printing diagnostic and log mes‐
103 sages. When the server sees an attribute name in a configuration
104 file, it looks up that attribute by name in the dictionary, and
105 uses the definition found there.
106 VALUE attribute-name value-name number
109 Define an attribute value name to number mapping, for an attribute
110 of type integer. The attribute-name field MUST be previously
111 defined by an ATTRIBUTE entry. The value-name field can be any
112 non-space text, but is usually taken from RFC2865, or other docu‐
113 ments.. The number field is also taken from the relevant docu‐
114 ments, for that name.
115 When the server receives an encoded value in a RADIUS packet, it
117 looks up the value of that attribute by number in the dictionary,
118 and uses the name found there for printing diagnostic and log mes‐
119 sages.
120 VENDOR vendor-name number [format=...]
122 Define a Vendor Specific Attribute encapsulation for vendor-name
123 to number. For a list of vendor names and numbers, see
124 http://www.iana.org/enterprise-numbers.txt.
125 The "format=t,l" statement tells the server how many octets to use
127 to encode/decode the vendor "type" and "length" fields in the
128 attributes. The default is "format=1,1", which does not have to
129 be specified. For USR VSA's, the format is "format=4,0", for
130 Lucent VSA's it's "format=2,1", and for Starent VSA's it's "for‐
131 mat=2,2".
132 The supported values for the number of type octets (i.e. the first
134 digit) are 1, 2, and 4. The support values for the number of
135 length octets (i.e. the second digit) are 0, 1, and 2. Any combi‐
136 nation of those values will work.
137 BEGIN-VENDOR vendor-name
140 Define the start of a block of Vendor-Specific attributes. All of
141 the following ATTRIBUTE definitions are interpreted as being for
142 the named vendor, until the block is closed by an "END-VENDOR"
143 statement.
144 This practice is preferred to placing the vendor name at the end
146 of an ATTRIBUTE definition.
147 For VSAs in the RFC 6929 "Extended vendor-specific" space, a for‐
149 mat can be specified following the "vendor-name". The format
150 should be "format=Extended-Vendor-Specific-1", through "for‐
151 mat=Extended-Vendor-Specific-6". The matching "END-VENDOR" should
152 just have the "vendor-name", without the format string.
153 END-VENDOR vendor-name
155 End a previously defined BEGIN-VENDOR block. The "vendor-name"
156 must match.
157 $INCLUDE filename
159 Include dictionary entries from the file filename. The filename
160 is taken as relative to the location of the file which is asking
161 for the inclusion.
162 BEGIN-TLV name
164 This feature is supported for backwards compatibility with older
165 dictionaries. It should not be used. The new "oid" form for
166 defining the attribute number should be used instead.
167 END-TLV name
169 This feature is supported for backwards compatibility with older
170 dictionaries. It should not be used. The new "oid" form for
171 defining the attribute number should be used instead.
172
174 /etc/raddb/dictionary, /usr/share/freeradius/dictionary.*
175
177 radiusd(8), RFC2865, RFC2866, RFC2868 RFC6929
178 12 Jun 2015 dictionary(5)