We recommend using local variables inside of "unlang" sections instead of defining attributes in this fine. See the reference documentation for more information on local variables.
This file exists for two purposes:
1) defining local attributes in order to simplify the process of migrating from version 3 to version 4. We recommend removing these attributes, and using local variables instead.
2) Including alias dictionaries in order to simplify the process of migrating from version 3 to version 4. We recommend using the new names where possible.
Local dictionary definitions
This is the local dictionary file which can be edited by local administrators. It will be loaded after the main dictionary files are loaded.
FreeRADIUS will automatically load the main dictionary files from:
${prefix}/share/freeradius/dictionary
It is no longer necessary for this file to $INCLUDE the main
dictionaries from this file. However, if the $INCLUDE line is
here, nothing bad will happen.
Dictionaries per Virtual Server
v4 also supports a dictionary { … } subsection in a virtual
server. If the attributes are used only in one virtual server,
they shuld be defined there.
Editing the dictionary
Any new/changed attributes must be placed in this file.
The pre-defined dictionaries should not be edited.
See man dictionary for documentation on how dictionary
entries should be formatted.
All local attributes and $INCLUDE directives should
go into this files.
The attribute definitions here should use DEFINE, not ATTRIBUTE.
The DEFINE keyword is exactly like ATTRIBUTE, except it does not
require an attribute number.
As a result, there is no need to manually manage numbers.
Any attribute `DEFINE`d here will not go into a packet.
If you do want attributes to go into a RADIUS packet, you will need to use VSAs. This means requesting allocation of a Private Enterprise Code from http://iana.org/. We strongly suggest doing that only if you are a vendor of RADIUS equipment.
See RFC 6158 for more details: http://ietf.org/rfc/rfc6158.txt
Example attributes
The attributes below are examples. You should edit them as required, or add your own.
v3 Compatible names.
All of the attributes have been renamed from v3. This change was necessary in order to support new funtionality in v4. The unfortunate side effect of this change is that all of the names in SQL, LDAP, and the "files" module are incompatible with v4.
We recognize that is is difficult to change every entry in a database, especially when there’s no clear mapping between the "old" and "new" names. This renaming is made more complex because the "new" names need to be grouped and arranged in ways that the old ones were not.
The "old" names were all in flat lists, so that User-Name appeared next to Cisco-AVPAir. This organization was simple enough to work for 20 years, but its time has come. The new names are hierarchical, so that the organization is nested by definition.
For v4, the Cisco-AVPair attribute is called "AVPair", and it lives inside of the "Cisco" namespace, which in turn lives inside of the "Vendor-Specific" namespace. So the new name for Cisco-AVPair is Vendor-Specific.Cisco.AVPair.
This process continues for many thousands of vendor-specific attributes.
Happily, it is possible to (mostly) use the old names with v4. There are limitations, but it will mostly work. The main reason for enabling the old names is to try out v4 with a database that is also used by v3. This lets you test that v4 works, without going through a complex "upgrade everything" process.
The old v3 names are in "alias" dictionaries, in the ${dictdir}
directory. To find out where this directory is on your local
system, run "radiusd -h" or "radclient -h". Then look for the "-D"
command-line option, and it will tell you where the dictionary
files are located.
The v3 names are in ${dictdir}/radius/alias/VENDOR.txt where
VENDOR is the name of the vendor, which is taken from the VENDOR
definition in the v3 dictionaries.
You will need to add a `$INCLUD`E line for each vendor-specific dictionary which is used by your local system. The default v4 dictionaries do not enable all of v3 compatibility names.
Yes, we recognize that this process is a bit of work. However, we wish to encourage everyone using v4 to upgrade to using the new v4 features. Our experience shows that if we automatically enable "compatibility functions", then those compatiblity functions will be used for a decade. So we need to find a balance between upgrades and ongoing support. Easy upgrades will mean complex ongoing support. Complex upgrades make ongoing support easier, but also make it less likely that people will upgrade.
All of the v3 compatibility names are in the RADIUS namespace.