diff options
Diffstat (limited to '')
| -rw-r--r-- | man/man5/dictionary.5 | 185 |
1 files changed, 185 insertions, 0 deletions
diff --git a/man/man5/dictionary.5 b/man/man5/dictionary.5 new file mode 100644 index 0000000..ec63309 --- /dev/null +++ b/man/man5/dictionary.5 @@ -0,0 +1,185 @@ +.\" # DS - begin display +.de DS +.RS +.nf +.sp +.. +.\" # DE - end display +.de DE +.fi +.RE +.sp +.. +.TH dictionary 5 "12 Jun 2015" +.SH NAME +dictionary \- RADIUS dictionary file +.SH DESCRIPTION +The master RADIUS dictionary file resides in +\fI/etc/raddb/dictionary\fP. It references other \fIdictionary\fP +files located in \fI/usr/local/share/freeradius/\fP. Each dictionary +file contains a list of RADIUS attributes and values, which the server +uses to map between descriptive names and on-the-wire data. The names +have no meaning outside of the RADIUS server itself, and are never +exchanged between server and clients. +.PP +That is, editing the dictionaries will have NO EFFECT on anything +other than the server that is reading those files. Adding new +attributes to the dictionaries will have NO EFFECT on RADIUS clients, +and will not make RADIUS clients magically understand those +attributes. The dictionaries are solely for local administrator +convenience, and are specific to each version of FreeRADIUS. +.PP +The dictionaries in \fI/usr/local/share\fP SHOULD NOT be edited unless +you know exactly what you are doing. Changing them will most likely +break your RADIUS deployment. +.PP +If you need to add new attributes, please edit the +\fI/etc/raddb/dictionary\fP file. It's sole purpose is to contain +site-local definitions that are added by the local administrator. + +.SH FORMAT +Every line starting with a hash sign +.RB (' # ') +is treated as comment and ignored. +.PP +Each line of the file can contain one of the following strings: +.TP 0.5i +.B ATTRIBUTE name oid type [flags] +Define a RADIUS attribute name to number mapping. + +The \fIname\fP field is a printable field, taken from various +specifications or vendor definitions. It is most commonly used as a +series of words, separated by hyphens. e.g. "User-Name". +Vendor-specific attributes (VSAs) are prefixed by the vendor name, +e.g. "Cisco-AVPair". The names should be globally unique, as they are +used as a key to look up the properties of the attribute. + +The \fIoid\fP field is taken from the relevant specification for that +name. In most cases, it is a decimal number, such as "256". For +certain attributes, a "dotted number" notation is used, e.g. "1.2". +The "dotted number" notation is used only for certain attributes. + +The \fItype\fP field can be one of the standard types: + + string UTF-8 printable text (the RFCs call this "text") + octets opaque binary data (the RFCs call this "string") + ipaddr IPv4 address + date Seconds since January 1, 1970 (32-bits) + integer 32-bit unsigned integer + ipv6addr IPv6 Address + ipv6prefix IPV6 prefix, with mask + ifid Interface Id (hex:hex:hex:hex) + integer64 64-bit unsigned integer + +The \fItype\fP field can be one of the following non-standard types: + + ether Ethernet MAC address + abinary Ascend binary filter format + byte 8-bit unsigned integer + short 16-bit unsigned integer + signed 31-bit signed integer (packed into 32-bit field) + tlv Type-Length-Value (allows nested attributes) + ipv4prefix IPv4 Prefix as given in RFC 6572. + +The last (optional) field of an attribute definition are additional +flags for that attribute, in a comma-separated list. Previous +versions of the server allowed these flags to include a vendor name. +This behavior may still work, but it is deprecated, and is not +recommended. + +The options are: + + encrypt=# set encryption type 1, 2, or 3. + has_tag The attribute can have an RFC 2868 style tag + +The "encrypt" flag marks the attribute as being encrypted with one of +three possible methods. "1" means that the attribute is encrypted +with the method as defined in \fIRFC2865\fP for the User-Password +attribute. "2" means that the password is encrypted with the method +as defined in \fIRFC2868\fP for the Tunnel-Password attribute. "3" +means that the attribute is encrypted as per Ascend's definitions for +the Ascend-Send-Secret attribute. + +The "has_tag" flag marks the attribute as being permitted to have a +tag, as defined in \fIRFC2868\fP. The purpose of the tag is to allow +grouping of attributes for tunneled users. See \fIRFC2868\fP for +more details. + +When the server receives an encoded attribute in a RADIUS packet, it +looks up that attribute by number in the dictionary, and uses the +definition found there for printing diagnostic and log messages. When +the server sees an attribute name in a configuration file, it looks up +that attribute by name in the dictionary, and uses the definition +found there. + +.TP 0.5i +.B VALUE attribute-name value-name number +Define an attribute value name to number mapping, for an attribute of +type \fIinteger\fP. The \fIattribute-name\fP field MUST be previously +defined by an \fIATTRIBUTE\fP entry. The \fIvalue-name\fP field can +be any non-space text, but is usually taken from \fIRFC2865\fP, or +other documents.. The \fInumber\fP field is also taken from the +relevant documents, for that name. + +When the server receives an encoded value in a RADIUS packet, it looks +up the value of that attribute by number in the dictionary, and uses +the name found there for printing diagnostic and log messages. +.TP 0.5i +.B VENDOR vendor-name number [format=...] +Define a Vendor Specific Attribute encapsulation for \fIvendor-name\fP +to \fInumber\fP. For a list of vendor names and numbers, see +http://www.iana.org/enterprise-numbers.txt. + +The "format=t,l" statement tells the server how many octets to use to +encode/decode the vendor "type" and "length" fields in the attributes. +The default is "format=1,1", which does not have to be specified. For +USR VSA's, the format is "format=4,0", for Lucent VSA's it's +"format=2,1", and for Starent VSA's it's "format=2,2". + +The supported values for the number of type octets (i.e. the first +digit) are 1, 2, and 4. The support values for the number of length +octets (i.e. the second digit) are 0, 1, and 2. Any combination of +those values will work. + +.TP 0.5i +.B BEGIN-VENDOR vendor-name +Define the start of a block of Vendor-Specific attributes. All of the +following \fIATTRIBUTE\fP definitions are interpreted as being for the +named vendor, until the block is closed by an "END-VENDOR" statement. + +This practice is preferred to placing the vendor name at the end of an +\fIATTRIBUTE\fP definition. + +For VSAs in the RFC 6929 "Extended vendor-specific" space, a format +can be specified following the "vendor-name". The format should be +"format=Extended-Vendor-Specific-1", through +"format=Extended-Vendor-Specific-6". The matching "END-VENDOR" should +just have the "vendor-name", without the format string. +.TP 0.5i +.B END-VENDOR vendor-name +End a previously defined BEGIN-VENDOR block. The "vendor-name" must match. +.TP 0.5i +.B $INCLUDE filename +Include dictionary entries from the file \fIfilename\fP. The +\fIfilename\fP is taken as relative to the location of the file which +is asking for the inclusion. +.TP 0.5i +.B BEGIN-TLV name +This feature is supported for backwards compatibility with older +dictionaries. It should not be used. The new "oid" form for defining +the attribute number should be used instead. +.TP 0.5i +.B END-TLV name +This feature is supported for backwards compatibility with older +dictionaries. It should not be used. The new "oid" form for defining +the attribute number should be used instead. +.PP +.SH FILES +.I /etc/raddb/dictionary, +.I /usr/share/freeradius/dictionary.* +.SH "SEE ALSO" +.BR radiusd (8), +.BR RFC2865, +.BR RFC2866, +.BR RFC2868 +.BR RFC6929 |